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1.0 


SUMMARY 


During  the  detailed  design  effort  for  the  IAPSA  II  contract,  a candidate 
architecture  design  based  on  AIPS  fault-tolerant  system  building  blocks  was 
evaluated  for  its  ability  to  meet  the  demanding  performance  and  reliability 
requirements  of  a flight-critical  system.  This  effort  was  conducted  in 
accordance  with  the  IAPSA  II  prevalidation  methodology.  This  methodology 
was  defined  and  an  advanced  fighter  configuration  was  selected  during  an 
earlier  phase  of  this  contract.  A mission  analysis  of  the 
high-performance,  multirole,  twin-engine  fighter  was  conducted  to  define  a 
set  of  flight-critical  requirements  for  this  study  during  the  earlier 

effort. 

The  preliminary  evaluations  showed  that  the  candidate  needed  some 
refinements  to  meet  the  system  requirements.  It  is  significant  that 
several  weaknesses  in  the  candidate  architecture  became  apparent  that  were 
not  evident  in  the  initial  rough  performance  and  reliability  calculations. 
This  effort  shows  that  it  is  both  possible  and  preferable  to  perform 
detailed  evaluation  of  concepts  based  on  specifications  before  committing  a 
project  to  a hardware  and  software  design. 

The  refined  configuration  was  evaluated  for  reliability  using  improved 
Markov  modeling  techniques.  Although  this  was  much  better  than  earlier 
evaluation  techniques,  improvements  are  needed  in  the  handling  of  very 
large  systems  with  a high  degree  of  interdependency. 

A set  of  objectives  and  experiments  was  defined  for  testing  critical 
performance  characteristics  using  a small-scale  system.  The  small-scale 
system  consists  of  existing  proof-of-concept  AIPS  building-block  hardware 
and  software  components.  It  embodies  key  features  of  the  IAPSA  II  design 
and  will  be  used  to  explore  issues  identified  as  a result  of  the 
performance  and  reliability  modeling  effort.  Experimental  data  will  be 
obtained  that  verify  performance  estimates  obtained  during  the  preliminary 
simulation  effort  and  measure  timing  characteristics  critical  to  successful 
operation. 


1 


2 


2.0  INTRODUCTION 


The  purpose  of  this  report  is  to  document  the  results  of  the  detailed 
design  of  the  IAPSA  II  system.  This  effort  was  carried  out  using  the 
prevalidation  methodology  developed  during  an  earlier  phase  of  this 
contract.  This  report  discusses  the  preliminary  simulation  experiments  and 
the  reliability  evaluation  of  the  candidate  architecture  and  shows  how  they 
affect  the  resulting  design.  Additionally,  a small-scale  system  that 
captures  the  fundamental  characteristics  of  the  IAPSA  II  design  and  a plan 
for  using  it  in  AIRLAB  experimentation  are  defined. 

The  IAPSA  II  analysis  and  design  effort  is  the  continuation  of  a research 
and  technology  program  to  investigate  the  benefits  of  integrated  system 
architectures  and  to  demonstrate  by  experimentation  in  the  NASA  Langley 
Avionics  Integration  Research  Laboratory  (AIRLAB)  the  properties  of 
promising  architectures.  Work  under  previous  contracts  achieved  the 
following:  (1)  defined  major  characteristics  of  an  Integrated  Airframe 
Propulsion  Control  System  Architecture,  (2)  proposed  several  candidate 
system  configurations,  and  (3)  selected  one  as  a basis  for  a preliminary 

system  design. 

The  overall  objectives  of  the  IAPSA  II  program  are  (1)  analysis  and 
detailed  design  of  an  integrated  control  system  architecture  that  satisfies 
stringent  performance  and  reliability  requirements,  (2)  an  analytical  and 
experimental  approach  for  evaluating  the  architecture,  and  (3)  installation 
and  limited  experimentation  on  a small  scale  system  test  specimen  in 

AIRLAB. 

The  first  phase  of  this  contract,  documented  in  reference  1,  defined  an 
advanced  fighter  configuration  for  analysis,  a prevalidation  methodology, 
and  a candidate  architecture  based  on  the  use  of  fault-tolerant  system 
building  blocks.  The  advanced  fighter  is  a twin-engine  design  with  a high 
degree  of  coupling  between  the  propulsion  system  and  the  airframe.  A 
mission  analysis  was  conducted  on  mission  scenarios  for  this  fighter  to 
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derive  the  control  system  requirements.  These  requirements  formed  the 
basis  for  the  design  of  a control  system  architecture. 

The  methods  used  to  design  and  validate  the  control  system  architecture  are 
as  important  to  the  IAPSA  II  contract  as  the  architecture  itself.  The 
prevalidation  methodology  defined  in  reference  1 emphasizes  the  early 
evaluation  of  key  performance  and  reliability  characteristics  of  system 
concepts  using  models  of  system  behavior.  This  early  evaluation  ensures 
that  the  system  design  is  capable  of  meeting  critical  requirements.  System 
concept  changes  needed  to  meet  these  requirements  can  then  be  made  early 
when  they  have  the  greatest  performance  benefit  and  the  least  impact  on 
schedule  and  cost.  Key  performance  and  reliability  assumptions  identified 
by  the  modeling  effort  will  be  tied  to  activities  to  validate  the 
implemented  system. 

A candidate  system  architecture  defined  by  our  subcontractor,  Charles  Stark 
Draper  Laboratory  (CSDL),  was  evaluated  to  exercise  the  methodology.  The 
basic  outline  of  the  candidate  architecture  is  provided  in  chapter  five  of 
reference  1.  The  more  detailed  definition  of  the  candidate  system 
necessary  to  support  the  modeling  effort  is  presented  in  sections  3 and  4. 
The  reliability  evaluation  effort  was  accomplished  in  four  parts:  (1) 
system  operating  details  and  key  reliability  assumptions  were  defined  to 
support  system  modeling;  (2)  based  on  the  key  reliability  measures 
(safety,  mission  success,  etc.),  a failure  analysis  was  conducted  to  define 
how  the  system  fails;  (3)  the  ASSIST  program  was  used  to  create  a 
corresponding  failure  model;  and  (4)  the  SURE  model  was  executed  and  its 
results  used  to  indicate  the  candidate's  strengths  and  weaknesses.  The 
reliability  effort  is  covered  in  section  3. 

The  performance  characteristics  of  the  candidate  architecture  were 
evaluated  in  normal  and  failure  situations  as  required  by  the  prevalidation 
methodology.  The  evaluation  effort  consisted  of  four  major  parts:  (1)  the 
key  application  sequencing  and  control  options  in  the  candidate  system  were 
defined;  (2)  critical  performance  issues  and  simulation  experiments  were 
defined  for  the  candidate  configuration;  (3)  a model  of  the  critical 
system  workload  and  its  use  of  the  configuration  elements  was  built  using 
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the  DENET  tool;  and  (4)  the  DENET  experiments  were  executed  and  the  results 
analyzed.  This  performance  evaluation  effort  is  described  in  section  4 of 

this  report. 

The  candidate  system  evaluation  described  in  sections  3 and  4 showed  that 
it  was  not  capable  of  meeting  the  system  requirements.  The  predicted 
safety  and  mission  reliability  values  exceeded  the  system  constraints. 
Additionally*  the  predicted  timing  needs  of  the  major  control  functions 
executing  on  the  concept  system  did  not  leave  adequate  growth  capability. 
The  flight  control  group  application  workload  strained  the  system  capacity 
in  both  computing  and  I/O  activity.  As  a result  the  IAPSA  II  system 
concept  was  refined  to  improve  its  performance  and  reliability.  The  three 
approaches  taken  to  refine  the  candidate  architecture  to  better  match  the 
system  needs  are  described  in  section  5.  The  results  of  a detailed 
reliability  evaluation  of  the  refined  configuration  and  a preliminary 
performance  analysis  are  also  presented  in  this  section. 

Section  6 outlines  the  objectives  and  presents  experiment  definitions  for 
the  small-scale  system  testing  effort.  The  small-scale  system  embodies  key 
features  of  the  IAPSA  II  design  that  will  be  evaluated  in  a limited 
experimentation  effort.  The  limited  effort  will  explore  a set  of  critical 
aspects  of  the  IAPSA  II  candidate  architecture  that  were  identified  as  a 
result  of  the  performance  and  reliability  modeling  effort.  The  small-scale 
system  consists  of  existing  proof-of-concept  AIPS  building-block  hardware 
and  software  components.  Two  kinds  of  experimental  data  will  be  obtained. 
First,  certain  performance  estimates  obtained  during  the  preliminary 
simulation  effort  will  be  verified.  Performance  simulation  results  will  be 
directly  compared  with  applicable  measurements  made  on  the  small-scale 
system.  Second,  certain  timing  characteristics  critical  to  successful 
operation  in  normal  and  faulted  situations  will  be  measured  experimentally. 

One  limitation  of  this  small-scale  system,  of  course,  is  that  system  level 
interactions  (e.g.,  communication  between  the  flight  control  group  and  the 
engine  groups)  cannot  be  tested.  Another  limitation  is  that  the 
experiments  must  make  use  of  existing  system  testability  features.  Because 
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existing  building  block  elements  are  used,  no  new  "hooks"  or  test  points 
can  be  used  to  enhance  visbility  during  experimentation. 
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3.0 


CANDIDATE  ARCHITECTURE  EVALUATION 


The  prevalidation  methodology  defined  in  reference  A emphasizes  the  early 
evaluation  of  key  performance  and  reliability  characteristics  of  system 
concepts  using  models  of  the  system  behavior.  Early  evaluation  ensures 
that  the  system  design  is  capable  of  meeting  critical  requirements.  System 
concept  changes  needed  to  meet  these  requirements  can  then  be  made  early 
when  they  have  the  greatest  performance  benefit  and  the  least  effect  on 
schedule  and  cost.  In  the  IAPSA  II  detailed  design  effort  a candidate 
system  architecture  defined  by  our  subcontractor,  Charles  Stark  Draper 
Laboratory  (CSDL),  was  evaluated  to  exercise  the  methodology.  The  basic 
outline  of  the  candidate  architecture  was  provided  in  chapter  five  of 
reference  A.  A more  detailed  definition  of  the  candidate  system  necessary 
to  support  the  modeling  effort  is  developed  in  sections  3 and  4.  Section  3 
deals  with  reliability  issues  and  section  4 with  performance  issues. 

To  support  system  modeling,  three  key  aspects  of  the  system  must  be 
defined:  (1)  function  partitioning,  (2)  physical  and  functional 
interconnection,  and  (3)  failure  protection.  Function  partitioning  defines 
how  the  system  functions  (or  processes)  are  allocated  to  system 
configuration  elements.  Interconnection  defines  how  the  system  elements 
are  interrelated.  Finally,  failure  protection  describes  how  the  critical 
system  functions  are  preserved  when  system  elements  fail.  The  following 
sections  will  provide  elaboration  of  these  characteristics  for  the 
candidate  architecture. 

3.1  Development  of  Major  Control  Functions 

The  IAPSA  II  system  performs  control  functions  that  are  critical  to  the 
flight  safety  and  mission  effectiveness  of  an  advanced  fighter.  Table  3.1- 
1 presents  the  major  control  functions  developed  for  the  vehicle  in 
reference  1.  These  functions  impose  demanding  performance  and  reliability 
requirements  on  the  system.  Furthermore,  the  designed  system  must  have  the 
capacity  to  handle  the  demanding  workload  of  these  functions  in  normal 
situations  and  in  failure  situations  where  a specified  level  of  performance 
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Table  3.1-1.  tAPSA  II  Major  Control  Functions 


System  functions 

Capabilities 

Needed  for: 

Manual  control 

Basic  flight  path  control 

SFL 

Flutter  control 

High  speed  ingress  with  stores 

FMC 

Trajectory  following 

Track  optimized  flight  paths 

FMC 

Wing  camber  control 

Optimized  wing  performance  for 
mission  segment 

FMC 

Trim  control 

FMC 

Inlet  control 

Full  supersonic  capability 

FMC 

Engine  control 

SFL 

Nozzle  control 

Thrust  vectoring/reversing 

FMC 

Notes: 

SFL:  Safe  flight  and  landing 
FMC:  Full  mission  capability 


must  be  provided  after  faults.  The  specific  reliability  goals  are  that  (1) 
the  system  contribution  to  loss  of  aircraft  probability  will  be  less  than 
10-7  for  a 3-hour  flight,  and  (2)  the  system  contribution  to  loss  of 
mission  probability  will  be  less  than  10-4.  The  major  control  functions  are 
developed  in  more  detail  in  the  following  sections. 

Table  3.1-1  specifies  the  high-level  capability  provided  by  each  major 
control  function.  Two  of  the  major  functions,  manual  control  and  engine 
control,  are  needed  to  allow  continued  flight  to  a safe  landing.  The  rest 
of  the  functions  are  needed  to  provide  full  mission  capability.  No  attempt 
was  made  during  the  reliability  study  to  distinguish  lesser  or  intermediate 
levels  of  mission  capability.  The  effects  of  system  element  failures  and 
combinations  of  failures  were  categorized  in  terms  of  the  three  system 
failure  conditions:  safe  flight  and  landing  (SFL) , fully  mission  capable 
( FMC ) , and  unsafe. 

The  major  control  functions  have  specific  sensing  and  actuation 
requirements.  These  requirements  are  shown  for  each  of  the  major  control 
functions  in  figures  3.1-1  through  3.1-8.  The  figures  also  list  the 
required  cyclic  execution  rate  derived  in  the  function  development  effort 
documented  in  reference  1.  The  major  control  functions  were  decomposed 
into  subfunctions  based  on  this  information.  The  resulting  subfunction 
definition  and  data  transfer  details  are  presented  in  the  following  two 
subsections. 

3.1.1  Derivation  of  Subfunctions 

The  IAPSA  II  functional  design  was  developed  in  more  detail  by  decomposing 
the  major  control  functions  into  subfunctions.  The  design  at  the 
subfunction  level  identifies  the  sensor  and  actuator  redundancy  management 
processes.  The  detailed  development  was  based  on  several  ground  rules.  A 
major  design  ground  rule  is  the  sharing  of  sensors  and  computing  processes 
among  the  major  functions.  If  more  than  one  function  requires  a particular 
computed  parameter,  it  is  computed  only  once. 
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Figure  3. 1-1.  Flutter  Control  Function 
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Figure  3. 1-2.  Manual  Control  Function 
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Body  normal 
acceleration 


Dynamic 

pressure 


Right  and  left  leading 
edge  flap  commands 


Mach 

number 


Wing  camber  control 
(50  Hz,  20  MSEC) 


Right  and  left 
trailing  edge  flap 
commands 


Pilot's  flap 
command 


Right  and  left  flaperon 
commands  (inboard  and 
outboard) 


Figure  3. 1-3.  Wing  Camber  Control  Function 
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Left  and  right 
canard  command 


Left  and  right 
rudder  command 


Left  and  right 
flaperons  command 
(inboard,  outboard) 


Nosewheel  commands 


Thrust  command 


Thrust  vector 
command  (nozzles) 


Maneuver  anticipation 
(engines,  inlets) 


Figure  3. 1-4.  Trajectory  Following  Function 
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Right  and  left 
trailing  edge  flap 
position 


Right  and  left 
flaperons  position 
(IB&OB) 


Right  and  left 
rudder  position 


Right  and  left 
canard  position 


Right  and  left 
nozzle  flap 
positions  (upper 
and  lower) 

Pilot's  trim 
commands  (pitch, 
roll,  yaw) 


Right  and  left 
trailing  edge  flap 
commands 


Right  and  left 
flaperon  commands 
(inboard  and 
outboard) 

Right  and  left 
rudder  commands 


Right  and  left  canard 
comands 


Right  and  left 
nozzle  flap 
commands  (upper 
and  lower) 


Figure  3.1-5.  Trim  Control  Function 
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Right  and  left  inlet 
ramp  commands 


Right  and  left  bypass 
ring  commands 


Figure  3.1-6.  Inlet  Control  Function 
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Mam  fuel  metering 
commands 


Afterburner  fuel 
metering  commands 
(5  per  engine) 

Main  fuel  shutoff 
commands 


Afterburner  fuel 
shutoff  commands 
(5  perengine) 


Fan  guide  vane 
commands 


Compressor  guide 
vane  commands 


Nozzle  area  command 


Figure  3.1-7.  E ngine  Control  Function 
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The  shared  elements  must  satisfy  the  requirements  of  all  dependent 
functions.  This  means  that  a shared  sensor  must  have  adequate  performance 
and  adequate  failure  protection  for  its  most  critical  user.  For  shared 
computing  processes,  the  most  demanding  function  defines  the  failure 
protection  requirement  and  also  sets  the  cyclic  execution  rate.  For  this 
study,  the  rate  used  for  all  derived  subfunctions  and  sensor  and  actuator 
signaling  is  based  on  the  fastest  control  function.  Detailed  control  lav 
performance  analysis  might  show  that  some  of  these  rates  can  be  relaxed; 
hovever , because  control  lav  design  and  analysis  is  beyond  the  scope  of  the 
contract,  this  possibility  vas  not  investigated. 

The  resulting  central  computing  subfunctions  are  presented  in 
figures  3. 1.1-1  through  3.1.1-15. 

The  first  group  of  figures  (3. 1.1-1  through  3.1.1— 8)  are  organized  by  major 
control  function.  The  sensor  management  computing  subfunctions  shovn 
perform  the  redundancy  management  for  sensor  failures.  The  process 
provides  parameter  estimates  to  all  using  functions.  The  actuator 
management  functions  shovn  on  the  figures  have  tvo  purposes:  first,  they 
combine  actuator  commands  from  all  control  lav  functions  that  share  the 
control  surface  or  device;  second,  they  perform  any  necessary  central 
actuator  redundancy  management.  Failure  protection  details  are  covered  in 
section  3.3. 

The  next  tvo  figures  (3. 1.1-9  and  3.1.1-10)  detail  the  inertial  data  and 
air  data  sensor  processing  subfunctions.  Both  processes  have  subfunctions 
that  execute  at  different  rates  to  support  different  users.  Air  data 
computing  is  divided  into  tvo  rates.  The  fast  rate  provides  the  sensor 
redundancy  management  and  the  computing  needed  by  the  inlet  control 
function.  The  slov  rate  provides  the  redundancy  management  functions  for 
the  rest  of  the  sensors  and  calculated  variables  needed  by  the  trajectory- 
folloving  function.  Inertial  data  has  a fast  subfunction  that  does  some 
redundancy  management  and  estimation  necessary  for  the  flutter  lav.  The 
rest  of  the  inertial  data  processing  can  be  done  at  a slover  rate.  Note 
that  these  figures  only  shov  the  interfaces  for  the  integrated  control 
functions.  In  a complete  system,  air  data  and  inertial  data  are  also 
needed  by  the  pilot  display  functions  of  the  pilot-vehicle  interface. 
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Figure  3. 1.1-1.  Flutter  Subfunctions 
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Figure  3. 1.1-2.  Manual  Control  Subfunctions 
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Figure  3. 1.1 -4.  Trajectory  Sub  functions 
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Figure  3. 1.7-5.  Trim  Subfunctions 
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Figure  3. 1.1-8.  Nozzle  Subfunctions 
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Figure  3. 1. 1-9.  Inertial  Subfunctions 


Actuator  cmd  (4) 
Actuator  mode  (4) 


Figure  3. 1. 1-1 1.  Pitch  Coordination  Subfunctions 
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Figure  3.1.1-13.  TE  Flap  Management 
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Actuator  cmd  (4) 
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Figure  3.1.1-14.  Rudder  Management 
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Actuator  cmd  (2) 
Actuator  mode  (2) 


Figure  3. 1. 1-15.  Nosewheel  Management 
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A pitch  coordination  subfunction  handles  the  blending  of  control  effectors 
for  longitudinal  axis  control.  This  allocation  is  primarily  one  of 
convenience.  It  provides  a coordinated  interface  for  the  pitch  control 
surfaces  and  the  vectored  nozzle.  Another  integrated  control  design 
alternative  might  signal  the  actuator  devices  directly,  without  the  need 
for  an  explicit  coordination  process. 

The  subfunction  figures  conclude  with  the  actuator  management  subfunctions. 
These  figures  show  which  major  functions  interface  to  each  set  of 
actuators. 

The  candidate  architecture  definition  from  reference  1 allocated  the 
IAPSA  II  computing  functions  to  the  flight  control  computing  site  and  to  an 
engine  control  computing  site  for  each  engine.  The  resulting 
staightforward  allocation  of  computing  subfunctions  and  associated  update 
rates  are  shown  in  tables  3. 1.2-1  and  3. 1.2-2.  The  pitch  coordination 
subfunction  responsible  for  pitch  control  blending  is  performed  at  the 
flight  control  site.  The  engine  control  site  performs  the  nozzle  actuator 
management  subfunction.  Note  that  the  execution  rates  for  the  slower 
functions  at  the  flight  control  site  have  been  adjusted  upward.  By 
maintaining  an  integer  multiple  relationship  between  all  rates,  potential 
problems  associated  with  tasks  drifting  in  and  out  of  phase  with  each  other 
are  avoided.  The  figures  show  the  computing  allocation  for  the  functions 
of  the  candidate  architecture  to  be  discussed  in  this  section  and  section  4 
as  well  as  the  refined  configuration  discussed  in  section  5. 

In  addition  to  division  by  computing  sites,  the  subfunctions  are  also 
organized  into  units  by  rate  group.  That  is,  all  subfunctions  executing  at 
one  site  at  the  same  cyclic  execution  rate  are  treated  together.  This  has 
performance  implications  in  terms  of  decreased  overhead  processing 
necessary  for  sequencing  and  control  of  the  application  computing,  which 
are  discussed  in  section  4.  The  results  of  this  grouping  are  special  data 
transfer  requirements  incorporated  into  the  system  design.  Note  that  these 
are  examples  of  requirements  that  are  due  to  the  way  the  system  is 
implemented. 
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Table  3. 1.2-1.  Computing  Allocation  - Flight  Control 


100  Hz 

50  Hz 

25  Hz 

12.5  Hz 

Wing  accelerometer  SM 

Pilot  command  SM 

Trajectory  law1 

Trim  command  SM 

Flutter  law 

Manual  law 

Slow  air  data  SM1 

Trim  law 

Body  rate  SM 

Camber  law 

Slow  air  data  calculation 1 

Fast  air  data  SM1 

LE  flap  AM 

Fast  air  data  calculation1 

Body  accelerometer  SM 

Flaperon  AM 

Inertial  calculation 

TE  flap  AM 

Pitch  coordination 

Canard  AM 

Rudder  AM 

Nosewhee!  AM 

Flap  command  SM 

SM  -Sensor management 
AM  -Actuator management 
1 - Reference  configuration 
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Table  3. 1.2-2.  Computing  Allocation  - Engine  Control 


100  Hz 

50  Hz 

25  Hz 

Inlet  SM 

Nozzle  AM 

Pilot  thrust  SM 

inlet  law 

Fan  face  SM 

Inlet  ramp  AM 

Engine  SM 

Inlet  ring  AM 

Fuel  flow  SM 

Fast  air  data  SM2 

Engine  law 

Fast  air  data2  calculation 

Main  fuel  AM 

Afterburner  fuel  AM 

Fan  guide  vane  AM 

Compressor  guide  vane  AM 

Trajectory  law2 

Slow  air  data  SM2 

Slow  air  data  calculation2 

Notes: 

SM  -Sensor  management 
AM  - Actuator  management 
2 -Refined  configuration 
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3.1.2  Derivation  of  Data  Transfer 


Any  data  transfer  between  functions  in  different  computing  sites  must  take 
place  on  the  intercomputer  (IC)  network.  Intercomputer  data  transfer  takes 
place  between  independent  computers.  A computer  with  data  must  first  gain 
access  control  of  the  network  and  then  transmit  its  message.  The  receiving 
computer  processes  the  message  based  on  its  priority  and  the  current 
processing  workload.  A key  assumption  is  that  the  corresponding  time  delay 
is  acceptable  to  the  control  law  performance.  As  discussed  in  section  4, 
IC  network  operation  was  not  modeled  in  this  study. 


Data  transfer  among  subfunctions  in  different  rate  groups  at  the  same  site 
will  generate  intertask  activity.  The  integrity  of  such  transfers  will 
undoubtedly  be  protected  by  some  operating  system  kernel  or  executive 
system  service.  This  protection  will  require  some  overhead  processing  and 
corresponding  time  delay.  The  operation  of  these  features  was  not  modeled 

in  this  study. 

The  activity  in  these  two  categories  resulting  from  the  candidate  system 
computing  allocation  is  presented  in  table  3. 1.2-3.  The  data  in  this  table 
are  listed  under  the  major  subfunction  that  is  the  data  source. 

3.2  Reference  Configuration  Layout 

The  physical  configuration  of  the  IAPSA  II  candidate  architecture  is  shown 
in  figure  3.2-1.  The  components  are  arranged  in  three  major  groups:  (1)  a 

flight  control  group,  (2)  a right  engine  control  group,  and  (3)  a left 
engine  control  group.  The  candidate  makes  extensive  use  of  advanced 
information  processing  system  (AIPS)  fault-tolerant  system  building  blocks. 
These  are  the  fault-  and  damage-tolerant  IC  networks,  input/output  (I/O) 
networks,  and  FTP.  These  elements  are  described  in  detail  in  reference  1, 

appendix  A. 

The  flight  control  group  consists  of  flight  control  sensors  and  actuators 
connected  to  a quadruple-channel  FTP  via  two  I/O  networks.  The  FTP 
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Table  3. 1.2-3.  Data  Transfer  Activity  by  Source 


Major  subfunction  (rate) 

1C  activity 

Intertask  activity 

Manual  law  (50) 

Maneuver  anticipation 

Flaperon  commands 

Camber  law  (50) 

TE  flap  commands 
Flapperon  commands 

Trajectory  law  (25) 

Thrust  commands 
Maneuver  anticipation 
Rudder  commands2 
Flaperon  commands2 
Nosewheel  command2 
Maneuver  command2 

Rudder  commands1 
Flaperon  commands1 
Nosewheel  command1 
Maneuver  com m a nd 1 

Trim  law  (1 2.5) 

TE  flap  commands 
Flaperon  commands 
Rudder  commands 
Pitch  trim  command 

Engine  (25) 

Throttle  position1 

Nozzle  area  commands 

Nozzle  (50) 

Thrust  vectoring  position 

Inertial  (100/50) 

Body  rates2 
Body  accelerations2 
Roll  angle2 
Heading2 

Pitch  attitude  rate2 
Vertical  acceleration2 
Flight  path  acceleration2 

Body  rates 
Body  accelerations 
Roll  angle1 
Heading1 

Pitch  attitude  rate1 
Vertical  acceleration1 
Flight  path  acceleration1 

Air  data  (100/25) 

Angle  of  attack2 
Angle  of  sideslip2 
Mach 

Dynamic  pressure 
Static  pressure1 

Angle  of  attack1 
Angle  of  sideslip1 
Mach 

Dynamic  pressure 
Static  pressure 

Pitch  coordination  (50) 

Thrust  vector  command 

Flaperon  AM  (100) 

Flaperon  position 

TE  flap  AM  (100) 

TE  flap  position 

Rudder  AM  (50) 

Rudder  position 

1 Reference  configuration 

2 Refined  configuration 
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Figure  3.2-1.  Reference  Configuration  Overview 
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channels  are  physically  dispersed  for  damage  tolerance.  Each  of  the  two 
engine  groups  controls  the  operation  of  one  of  the  tvo  propulsion  systems. 
An  engine  group  consists  of  the  sensors  and  actuators  of  one  propulsion 
system  connected  to  a triple-channel  FTP  through  two  I/O  networks.  The 
three  groups  are  interconnected  by  an  IC  network  joining  the  three 
computing  sites.  The  following  two  subsections  present  details  about  the 
flight  and  engine  groups  from  an  I/O  network  point  of  view. 

3.2.1  Flight  Control  I/O  Network 

One  of  the  two  flight  control  I/O  networks  is  shown  in  figure  3. 2. 1-1. 
Half  of  the  flight  control  sensors  and  actuators  are  connected  to  network 
1;  half  are  connected  to  network  2.  The  sensors  and  actuators  interface 
the  network  through  device  interface  units  (DIU).  The  DIU  provides  signal 
conditioning  and  conversion  for  the  devices  and  handles  the  network 
communication  protocol.  Each  DIU  connects  to  a single  network  node.  The 
lack  of  cross-connection  between  sensor  and  actuators,  nodes,  and  DIUs 
alleviates  any  fault  containment  concerns.  This  form  of  "brickwalled" 
system  organization  introduces  an  element  of  dependency  into  the  system, 
which  will  be  evaluated  in  the  reliability  analysis. 

The  I/O  network  consists  of  a mesh  of  18  nodes  connected  by  full  duplex 
point-to-point  links.  The  nodes  can  be  commanded  to  turn  links  on  or  off. 
In  operation,  enough  links  are  turned  on  to  create  a path  from  the  FTP  to 
all  nodes  and  DIUs  in  the  network.  The  remaining  links  act  as  spares. 
Each  network  node  in  the  candidate  architecture  is  connected  to  three  other 
network  nodes.  This  means  that  two-thirds  of  the  links  are  active  and  the 
remaining  one-third  are  spare  during  operation.  With  three  connections,  at 
least  three  faults  are  necessary  to  destroy  communications  with  a good  node 
and  its  attached  devices. 

The  flight  control  I/O  networks  are  connected  to  the  FTP  with  three  root 
links,  each  connected  to  a different  channel.  During  operation,  only  one 
of  the  root  links  is  active,  and  the  others  act  as  spares.  With  three  root 
links,  at  least  three  faults  must  occur  to  isolate  an  entire  network  of 
sensors  and  actuators. 
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Figure  3 2.1-1  Flight  Control  I/O  Network  1 Layout 


The  redundant  flight  control  sensors  and  actuators  are  spread  evenly  across 
the  two  networks  and  the  redundant  DIUs.  The  specific  assignment  of  these 
elements  is  shown  in  table  3. 2. 1-1.  The  safety-critical  flight  control 
sensors  are  primarily  quadruple  redundant.  The  skewed  body  motion  sensors 
are  an  exception  because  a different  redundancy  level  is  required  to 
achieve  the  same  degree  of  failure  protection.  A total  of  eight  were 
needed  in  the  IAPSA  I system  due  to  interconnection  dependencies.  Eight 
were  used  in  the  candidate  architecture  because  a similar  situation  exists 
for  IAPSA  II.  The  mission-critical  flight  control  sensors  are  triple 
redundant.  The  flight  control  surface  actuators  have  a dual  redundant 
control  channel  arrangement.  Each  actuator  channel  is  connected  to  a 
different  network  and  is  capable  of  full  operation.  If  communications  to 
one  channel  of  the  actuator  are  interrupted  for  any  reason,  control  can  be 
maintained  through  communications  on  the  unaffected  network.  Failure 
protection  details  for  these  elements  will  be  provided  in  section  3.3. 

3.2.2  Engine  Control  I/O  Network 

The  two  I/O  networks  for  one  propulsion  system  are  shown  in  figure  3. 2. 2-1. 
Like  the  flight  control  arrangement,  the  propulsion  control  sensors  and 
actuators  are  connected  half  to  one  network  and  half  to  the  other  network. 
The  devices  are  also  connected  in  a "brickwall"  manner,  with  one  device 
connected  to  only  one  DIU,  which  in  turn  is  connected  to  only  one  network 
node  and  therefore  one  network. 


The  engine  control  networks  each  contain  four  nodes,  and  because  the 
network  is  a system  building  block  entity,  its  operation  is  identical  to 
the  flight  control  networks.  Like  the  flight  control  network,  each  network 
node  is  connected  to  three  network  links.  Unlike  the  flight  control 
network,  each  network  is  connected  to  the  FTP  through  two  root  links,  which 
means  that  an  entire  set  of  sensors  and  actuators  can  be  isolated  after  two 
failures. 

The  candidate  system  requires  a lower  level  of  failure  protection  for  each 
propulsion  system  because  safe  flight  and  landing  is  possible  after  loss  of 
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Table  3.2 . 1- 1.  Sensor/Actuator  Connection  - Flight  Control  Networks 


Devices 


Body  accelerometers 


Body  gyros 


Angle  of  attack 


Angle  of  sideslip 


Static  pressure 


Total  pressure 


Total  temperature 


Redundancy 


DIU/node  ID 


Rudder  pedal 


Left  throttle 


Right  throttle 


Flap  lever 


Table  3.2. 1-1.  Sensor/Actuator  Connection  - Flight  Control  Networks  (Continued) 


Devices 

Redundancy 

DlU/node  ID 

NW 

Left  canard  actuation 

1 

CDL1 

1 

1 

CDL2 

2 

Right  canard  actuation 

1 

CDR1 

1 

1 

CDR2 

2 

Nosewheel  actuation 

1 

Nt 

1 

1 

N2 

2 

Leading  edge  actuation 

1 

LER 

1 

1 

LEL 

2 

L outboard  flaperon  actuation 

1 

OFL1 

1 

1 

OFL2 

2 

L inboard  flaperon  actuation 

1 

IFL1 

1 

1 

IFL2 

2 

LTE  flap  actuation 

1 

TEL1 

1 

1 

TEL2 

2 

L rudder  actuation 

1 

RL1 

1 

1 

RL2 

2 

R rudder  actuation 

1 

RR1 

1 

1 

RR2 

2 

R TE  flap  actuation 

1 

TER1 

1 

1 

TER2 

2 

R inboard  flaperon  actuation 

1 

IFR1 

1 

1 

IFR2 

2 

R outboard  flaperon  actuation 

1 

1 

OFR1 

OFR2 

1 

2 

L outboard  wing  accelerometers 

1 

OFL2 

2 

1 

OFL1 

1 

1 

IFL2 

2 

L mid-wing  accelerometers 

1 

IFL2 

2 

1 

IFL1 

1 

1 

TEL2 

2 

L inboard  wing  accelerometers 

1 

IFL1 

1 

1 

TEL2 

2 

1 

TEL1 

1 

R inboard  wing  accelerometers 

1 

2 

1 

1 

1 

2 

R mid-wing  accelerometers 

1 

TER1 

1 

1 

1FR2 

2 

1 

1FR1 

1 

R outboard  wing  accelerometers 

1 

1FR1 

1 

1 

OFR2 

2 

1 

OFR1 

1 
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O Node 


Figure  3.2.2 - 1.  Left  Engine  I/O  Network  Layout 


one  of  the  two  engines.  The  specific  assignment  of  the  redundant  sensors 
and  actuators  for  one  propulsion  system  is  presented  in  table  3. 2. 2-1. 
Notice  that  most  propulsion  system  sensors  are  dual  redundant.  An 
exception  is  the  engine  core  sensors  that  are  covered  by  an  analytic 
redundancy  management  scheme.  The  propulsion  system  actuators  are  dual 
channel.  Each  actuator  channel  is  connected  to  a different  I/O  network 
like  the  flight  control  actuators.  More  detail  on  the  failure  protection 
for  these  elements  is  presented  in  section  3.3. 

3.3  Reference  Configuration  Failure  Protection 

Failure  protection  is  the  central  issue  in  the  design  of  flight-critical 
systems.  To  provide  the  necessary  levels  of  safety  and  mission 
reliability,  the  system  must  be  able  to  tolerate  faults  without  affecting 
the  operation  of  its  critical  functions.  This  capability  is  provided  by 
redundancy  management  processes  that  are  responsible  for  the  detection  and 
identification  of  system  element  faults  and  any  necessary  reconfiguration 
of  functions  to  maintain  safety  or  mission  capability.  This  section  will 
discuss  the  failure  protection  assumptions  for  the  candidate  system. 
Elements  will  be  discussed  by  functional  category.  The  primary  function  of 
each  candidate  configuration  element  will  be  used  to  group  it  in  one  of 
four  major  categories:  computing,  data  transfer,  sensing,  or  actuation. 
Before  presenting  these  assumptions,  function  migration  will  be  discussed. 

A key  failure  protection  issue  for  the  candidate  architecture  is  function 
migration.  This  is  a high-level  scheme  that  can  be  used  on  the  group  level 
to  provide  failure  protection  for  the  computing  functions.  In  an  AIPS 
system,  function  migration  is  a nonroutine  change  of  computing  assignments 
for  the  different  system  computers.  An  external  stimulus  such  as  a fault, 
a change  in  mission  phase,  or  crew  direction  is  necessary  for  function 
migration.  An  early  design  decision  was  to  not  implement  this  capability 
for  failure  protection  in  the  candidate  architecture.  The  capability  was 
judged  to  be  relatively  immature  for  the  time  frame  of  the  IAPSA  II 
application. 
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Table  3.2.2- 1.  Sensor/Actuator  Connection  - Engine  Control  Networks 


Devices 


Redundancy 


DlU/node  ID 
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Function  migration  imposes  very  challenging  requirements  on  a system 
performing  flight-critical  functions  with  critical  timing  needs.  The 
function  must  be  reliably  terminated  at  one  computing  site  and  started  at 
another  with  minimum  delay.  Performance  transients  must  be  minor. 
Additionally,  communications  responsibility  for  the  associated  sensors  and 
actuators  must  be  transferred  to  the  new  site  with  minimum  delay.  For  the 
new  site  to  fulfill  this  responsibility,  there  must  first  be  a physical 
path  from  the  new  site  to  the  appropriate  networks.  Second,  all  the 
software  definitions  necessary  to  pick  up  the  periodic  communications  with 
the  devices  must  be  resident  at  the  new  site.  Finally,  the  new  site  must 
be  able  to  perform  redundancy  management  on  the  networks.  The  critical 
software  elements  are  AIPS  system  service  functions:  system  manager,  I/O 
services,  and  I/O  redundancy  management. 

The  decision  to  include  function  migration  would  necessitate  changes  to  the 
candidate  architecture.  Spare  links  would  be  needed  between  the  computing 
sites  and  the  networks  of  the  different  groups  to  support  the  alternative 
communications  capability.  The  I/O  networks  might  be  operated  differently, 
for  example,  as  regional  networks  instead  of  local  networks,  if  function 
migration  was  a possible  reconfiguration  action.  However,  because  of  the 
uncertain  availability  of  this  technique,  the  candidate  system  was 
evaluated  with  no  function  migration  capability. 

3.3.1  Application  Computing 

The  first  functional  category  for  the  failure  protection  discussion  is 
application  computing.  The  application  computing  functions  are  centered  on 
control  laws  that  provide  integrated  flight  and  propulsion  control 
capabilities.  These  control  laws  run  on  the  FTP  general-purpose  computers. 
A key  feature  of  the  AIPS  system  is  that  application  software  functions  can 
be  written  as  if  they  execute  on  a perfectly  reliable  single  channel 
computer.  The  AIPS  system  hardware  and  software  elements  provide 
protection  from  computing  element  failure. 

The  FTP  operating  concept  has  all  redundant  channels  executing  exactly  the 
same  software  in  instruction  synchronism.  All  of  the  computed  outputs  are 
voted  to  ensure  bit-for-bit  agreement.  An  unsuccessful  vote  points  out  a 
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faulty  channel.  All  inputs  go  through  a byzantine  fault-tolerant  data 
exchange  process  to  ensure  that  each  good  channel  is  operating  with  exactly 
the  same  data.  Special  fault-tolerant  clock  (FTC)  hardware  keeps  each 
channel  in  synchronization,  while  special  data  exchange  (DX)  hardware 
allows  for  fast,  reliable  exchange  of  interchannel  data. 

A key  element  of  the  FTP  concept  is  the  AIPS  system  software  FDIR  process. 
FDIR  has  the  overall  responsibility  for  FTP  redundancy  management.  The 
portion  of  FDIR  that  executes  most  frequently  is  called  Fast-FDIR.  This 
process  checks  every  cycle  for  indications  of  output  disagreement  and 
ensures  that  all  channels  are  in  instruction  synchronism.  When  necessary, 
processor  interlock  hardware  is  used  to  disable  faulty  channel  outputs. 
FDIR  programs  running  in  background  perform  self- tests  on  the  channel 
hardware.  A watchdog  timer  monitors  the  periodicity  of  the  channel  cyclic 
execution.  More  detailed  information  about  the  FTP  failure  protection  is 
provided  in  reference  1. 

Two  good  FTP  channels  are  needed  for  operation  when  a guaranteed  shutdown 
is  required  for  a subsequent  channel  fault.  Two  are  necessary  so  that 
comparison  between  channels  can  immediately  detect  the  fault.  The  FTP 
building  block  has  the  ability  to  be  safely  reconfigured  into  a special 
simplex  operating  mode  if  the  failures  can  be  rapidly  identified  by  self- 
test. This  ability  allows  for  continued  operation  for  those  which  do  not 
cause  a loss  of  synchronization.  However,  the  capability  to  degrade  to 
simplex  operation  was  not  evaluated  in  the  candidate  architecture.  Based 
on  this  decision,  the  quadruple  flight  control  computer  provides  fail- 
operational/fail-off  failure  protection  capability  for  the  safety-critical 
functions.  Similarly,  the  engine  computer  provides  fail-operational/fail- 
off  capability  for  each  propulsion  system. 

3.3.2  Application  I/O  Activity 

The  next  functional  category  is  data  transfer.  Sensor  and  actuator  data 
transfer  takes  place  on  the  I/O  networks.  As  previously  mentioned,  not  all 
of  the  links  in  the  mesh  network  are  active  during  operation.  During 
system  startup  before  flight,  two  out  of  three  mesh  network  links  are 
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activated  to  form  a virtual  communications  bus.  This  virtual  bus  provides 
a path  between  the  FTP  and  all  good  nodes  and  DIUs.  Responsibility  for 
maintaining  a communication  path  to  all  good  devices  during  operation  rests 
with  the  I/O  redundancy  management  process,  which  is  a software  building 
block  element  of  the  AIPS  system  services  software. 

Network  data  transfer  involves  many  of  the  FTP  hardware  and  software 
elements.  These  are  shown  in  figure  3. 3.2-1.  The  application  process 
requests  I/O  activity  from  one  of  the  AIPS  system  service  software 
processes,  which  primarily  resides  on  the  IOP  coprocessor.  The  network 
activity  called  for  by  the  I/O  request  consists  of  a sequence  or  chain  of 
transactions.  Each  transaction  involves  a command  message  addressed  to  a 
specific  DIU  followed  (usually)  by  a response  message  from  that  DIU.  Each 
chain  is  setup  for  execution,  initiated,  and  post  processed  by  the  services 
software  on  the  IOP.  Once  initiated,  the  chain  runs  without  IOP 
involvement.  The  network  interface  (NI)  hardware  sends  each  command 
message  and  receives  each  response  message  until  the  chain  sequence  is 
complete. 


The  NI  hardware,  which  transmits  and  receives  all  chains,  detects  and  logs 
network  protocol  errors.  Missing  response  messages  are  caught  by  the  NI 
timer  that  sets  a timeout  interval  for  each  transaction.  The  I/O  services 
process  implements  a chain  timeout  to  detect  faults  that  result  in  an 
incomplete  chain.  The  data  transfer  status  information  and  all  data 
returned  by  the  DIUs  are  distributed  to  all  FTP  channels  by  the  I/O 
services  through  the  data  exchange.  The  status  information  is  analyzed  by 
I/O  redundancy  management  and,  when  necessary,  network  repair  action  is 
taken  to  restore  communications. 

Most  network  repair  actions  command  nodes  to  enable  or  disable  network 
links  using  special  command  messages  over  the  I/O  network.  The  repair 
strategy  fundamentally  consists  of  turning  links  on  and  off  to  isolate 
faulty  network  elements  and  to  provide  an  alternate  data  path  to  the 
affected  DIU(s).  An  example  of  this  is  shown  in  figure  3. 3. 2-2,  where  a 
spare  link  is  used  to  bypass  a failed  active  link.  The  specific  repair 
action  must  be  based  on  fault  indications  available  to  I/O  redundancy 
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Figure  3. 3. 2-2.  Link  Failure  Reconfiguration 
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management  at  the  FTP.  Because  many  faults  have  similar  indications, 
special  chains  are  usually  necessary  before  the  repair  activity  to  help 
diagnose  the  fault.  In  some  cases,  the  fault  may  not  be  identified  except 
by  a process  of  elimination  during  the  repair  sequence.  Certain  candidate 
architecture  faults,  such  as  DIUs  or  nodes,  vill  permanently  disable  the 
directly  connected  sensors  and  actuators  because  no  alternative  path  is 
possible.  The  specific  I/O  network  repair  strategy  assumed  for  the 
candidate  architecture  is  discussed  further  in  section  4. 

3.3.3  Flight  Control  Sensing 

Most  of  the  safety  critical  sensors  listed  in  table  3. 2. 1-1  in  section  3.2 
were  quadruple  redundant  to  provide  full  operation  after  two  like  sensor 
failures.  Mission  critical  sensors  are  triple  redundant  to  provide  fail- 
operational/fail-off  failure  protection  for  the  mission-critical  control 
functions.  Voting  processes  executing  in  the  FTP  compare  redundant  sensor 
readings  to  detect  and  identify  sensor  failures.  These  voting  processes 
have  demanding  false  alarm,  missed  alarm,  and  failure  transient  performance 
requirements.  Sophisticated  dynamic  processes  are  used  to  meet  these  needs 
for  full-time  critical  operation.  Distinguishing  failures  from  normal 
channel  mismatches  is  a very  challenging  engineering  task.  As  a result,  a 
significant  failure  recovery  time  is  needed  to  react  to  a sensor  failure. 
Because  a comparison  process  is  used,  only  failure  detection  can  be 
accomplished  when  two  sensors  remain  operational. 


The  skewed  axis  sensor  readings  are  processed  to  provide  estimates  of  the 
three  axis  rates  and  accelerations.  A sophisticated  process  compares  the 
readings  for  consistency  in  order  to  detect  and  identify  sensor  failures. 
In  this  situation,  four  sensors  are  needed  for  the  process  to  provide 
failure  detection  capability.  Five  are  needed  to  identify  the  failed 

sensor. 

All  of  the  sensor  redundancy  management  processes  can  use  external 
information  to  aid  fault  identification.  When  data  is  unavailable  to  a 
comparison  process  because  of  a known  communication  fault,  operation  can  be 
continued  with  a single  remaining  sensor  (or  three  skewed  sensors). 
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However,  in  this  situation,  the  voting  process  is  unable  to  detect  a 
subsequent  sensor  fault. 

3.3.4  Flight  Control  Actuation 

Eight  primary  surfaces  provide  basic  flight  path  control.  At  least  two  of 
the  surfaces  contribute  most  of  the  control  moment  for  each  axis.  Pitch 
axis  control  is  provided  by  two  canards.  Two  flaperons  on  each  wing 
control  roll  axis  motion.  Similarly,  two  rudders  control  motion  around  the 
yaw  axis.  Secondary  surfaces  and  devices  include  leading  edge  flaps, 
trailing  edge  flaps,  and  nosewheel  steering. 

Each  surface  or  device  is  moved  by  a dual  actuator.  The  actuator  is  based 
on  a dual  coil-dual  monitored  valve  approach.  Figure  3. 3. 4-1  shows  the 
configuration  of  the  standard  actuator.  Most  of  the  actuator  components 
are  dual  with  the  exception  of  the  servodrive  and  valve  monitoring 
elements.  Two  processors,  each  of  which  has  the  capability  to  drive  both 
control  valves,  close  the  actuator  position  loop.  Position  errors  cause 
control  valve  movement  that  routes  hydraulic  flow  to  one  side  of  a dual 
tandem  power  ram. 

Local  redundancy  management  is  used  to  react  to  most  failures.  Special 
monitor  hardware  detects  most  failures  of  the  actuator  position  and  valve 
position  sensors.  Vhen  failures  are  detected,  the  other  actuator  processor 
can  take  control.  The  actuator  processor  computes  a model  of  the  control 
valve  dynamics  to  detect  valve  failure.  Valve  failure  will  lead  to  bypass 
of  that  side  of  the  dual  tandem  ram  and  continued  operation  using  the  other 
valve.  A self-test  process  and  watchdog  timer  hardware  detect  failures  of 
the  actuator  processor  hardware.  Detected  failures  result  in  control  of 
the  surface  by  the  other  processor. 

Some  actuator  failures  may  be  missed  due  to  a lack  of  coverage  by  the 
monitor  processes.  As  a last  line  of  defense,  the  actuator  management 
process  in  the  FTP  generates  a "safe"  command  for  the  surface  when  it  sees 
indications  of  an  unresponsive  surface.  Undetected  failures  may  lead  to 
force  fight  situations,  seen  as  a stuck  or  slowly  drifting  surface.  They 
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can  also  lead  to  a surface  moving  rapidly  hardover  if,  for  example,  the 
other  actuator  channel  has  been  bypassed  due  to  a previous  failure. 
Because  it  can  deactivate  an  entire  surface,  the  central  process  must 
satisfy  stringent  false  alarm  requirements.  It  must  correctly  handle 
anomalies  occurring  during  normal  operation  or  caused  by  failures  in  other 
system  elements. 

The  response  to  an  uncovered  failure  is  more  time  critical  in  the  case  of 
an  actuator  that  is  controlled  by  a single  channel  due  to  a previously 
detected  fault.  In  this  situation,  the  surface  may  be  moving  rapidly 
hardover  until  the  central  process  commands  passive  operation.  This 
condition  sets  the  time  response  requirements  for  the  central  actuator 
management  process. 

3.3.5  Propulsion  Control  Sensing 

As  previously  described,  most  of  the  propulsion  sensors  are  dual  redundant. 
For  the  candidate  system,  model-based  redundancy  management  processes  were 
assumed  to  allow  fail-operational/fail-off  failure  protection  capability. 
The  specific  approaches  used  for  the  different  sensors  are  described  in 
this  section. 

It  should  be  noted  that  a more  detailed  examination  and  definition  of  the 
propulsion  control  concept  was  carried  out  during  the  refined  configuration 
evaluation.  The  concept  and  failure  analysis  described  in  this  section 
were  reevaluated  during  that  study.  Shown  here  are  the  results  of  the 
initial  analysis.  The  results  of  more  detailed  evaluation  are  presented  in 
terms  of  changes  to  this  baseline  in  section  5. 

An  inlet  flow  model  identifies  failures  among  the  inlet  pressure  sensors, 
fan  face  sensors,  and  inlet  device  position  sensors.  The  model  executes  on 
the  engine  control  FTP  using  air  data  sensor  information  and  engine  fan 
speed.  It  identifies  the  failed  sensor  of  a pair  and  detects  a second 
like-sensor  failure  by  looking  for  an  inconsistency  among  the  measurements 
and  the  device  positions.  Loss  of  any  of  the  required  measurements  will 
deactivate  this  redundancy  management  process. 
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Throttle  command  sensor  management  uses  the  throttle  setting  of  the  other 
engine  to  help  identify  sensor  failures.  The  logic  assumes  that  the  two 
engine  commands  will  be  nearly  identical.  When  the  logic  indicates  that 
the  final  sensor  of  a pair  has  failed,  the  engine  reverts  to  a fixed-thrust 
operation.  In  this  situation,  or  at  any  time  the  engine  does  not  follow 
commands,  the  pilot  can  shut  the  engine  down  when  conditions  permit. 

Redundancy  management  for  the  engine  core  sensors  employs  a sophisticated 
algorithm  described  in  detail  in  reference  2.  The  core  sensors  include: 
fan  speed,  compressor  speed,  burner  pressure,  fan  turbine  inlet 
temperature,  and  afterburner  pressure.  The  analytic  redundancy  method 
detects  and  identifies  failures  among  the  five  sensor  types  to  provide 
fail-operational/fail-off  capability.  When  measurements  from  a specific 
sensor  type  are  lost,  the  algorithm  provides  an  estimated  sensor  value  to 
be  used  by  the  control  law.  In  addition  to  the  core  sensor  measurements, 
the  algorithm  needs  fuel  flow,  nozzle  area,  and  fan  and  compressor  guide 
vane  position  measurements  to  perform  its  function.  Some  of  the  core 
sensors  are  dual  redundant  to  maintain  failure  detection  capability  after 
communication  element  failures.  Because  the  sensors  are  divided  between 
two  node/DIUs,  one  failure  can  eliminate  half  of  them. 

The  afterburner  lightoff  detectors,  used  in  the  staged  control  of  the 
afterburner,  use  a simple  consistency  scheme  to  identify  detector  failures. 
The  scheme  is  based  on  the  commanded  afterburner  operating  mode.  When  the 
detectors  disagree,  the  one  consistent  with  the  commanded  operation  will  be 
used  while  the  other  is  declared  failed.  Similarly,  a remaining  detector 
indicating  uncommanded  lightoff  will  be  declared  failed.  If  the  remaining 
detector  fails  to  indicate  lightoff  when  operation  is  commanded, 
afterburner  sequencing  will  be  stopped. 

3.3.6  Propulsion  Control  Actuation 

All  propulsion  devices  employ  the  same  general  actuation  control  concept 
shown  in  figure  3. 3. 6-1.  A propulsion  actuator  is  basically  a dual-channel 
device  incorporating  fail-passive  electronics.  Each  channel  drives  its 
control  valve  based  on  the  error  between  the  position  command  from  the  DIU 
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Device  interface  units 


FPE 

Fail  passive  electronics 

2 

CO 

Coil 

2 

VLV* 

Control  valve 

2 

BYP 

Bypass  device 

1 

SOL 

Engage  solenoid 

2 

POS 

Position  sensor 

2 

DTR* 

Dual  tandem  ram 

1 

HYD 

Hydraulic  system 

2 

* Active  failure  mode 

Figure  3. 3. 6-1.  Propulsion  Actuation 
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and  the  position  feedback  sensor.  The  two  control  valves  are  mechanically 
linked  together.  Each  valve  controls  hydraulic  flow  to  one  side  of  the  dual 
tandem  power  ram.  Either  channel  can  engage  the  actuator  through  a dual 
solenoid-operated  bypass  valve. 

Generallyi  propulsion  actuation  element  failures  are  detected  using  self- 
test methods.  Failures  detected  in  the  electronic  elements  cause  one 
channel  to  fail  passive,  which  means  it  stops  driving  its  control  valve  and 
takes  away  its  engage  power  from  the  bypass  solenoid.  When  both  sides  fail 
passive,  disengagement  causes  the  device  to  move  to  a preferred  fixed 
position.  The  propulsion  system  operates  at  a degraded  performance  level 
when  one  of  its  devices  is  in  the  fixed  position.  This  will  be  further 
discussed  in  section  3.4. 

Failures  that  are  not  detected  by  the  self-test  methods  result  in 
disagreement  between  the  feedback  sensors  or  force  fight  at  the  control 
valve.  This  will  be  manifested  by  a stuck  or  slowly  drifting  propulsion 
device.  The  actuator  management  process  in  the  FTP  detects  this  situation 
and  commands  disengagement  to  force  the  device  to  move  to  its  preferred 
fixed  position.  Certain  mechanical  failures  in  the  actuator  will  also  be 
detected  by  the  central  redundancy  management.  Mechanical  jam  of  the 
control  valve  will  cause  the  device  to  move  toward  a hardover  position 
until  it  is  disengaged;  however,  mechanical  jam  of  the  power  ram,  which  is 
an  unlikely  failure  mode,  will  jam  the  device  permanently. 

A fuel  flow  model  identifies  metering  valve  position  sensor  failures  and 
fuel  flowmeter  failures.  The  model  can  identify  the  first  failure  of  a 
pair  of  sensors  and  detect  the  second  failure  to  provide  fail-op  /fail-off 
capability.  Its  operation  is  based  on  consistency  between  the  valve 
position  and  the  measured  flow. 

The  fuel  handling  portion  of  the  system  includes  special  fuel  shutoff 
devices  where  needed  for  additional  safety.  The  fuel  to  each  engine  passes 
through  a dual  device  fuel  shutoff  valve.  Either  shutoff  drive  can 
terminate  fuel  flow  to  the  engine.  This  capability  is  used  by  the  fuel 
metering  actuator  management  process  as  a last  resort  to  protect  against 


hazardous  overspeed  or  overtemperature  situations.  Additionally,  fuel  flow 
to  the  afterburner  incorporates  dual  solenoid  zone  flow  shutoff  valves. 
Either  drive  can  open  the  valve  to  allow  zone  flow  that  is  modulated  by  an 
afterburner  metering  valve.  Flow  to  a specific  zone  is  cut  off  when  neither 
solenoid  drive  is  powered.  Central  RM  commands  fuel  shutoff  if  continued 
operation  of  a specific  engine  is  hazardous,  for  example,  if  the  thrust 
vectoring  and  reversing  devices  won't  move  to  a safe  position. 

In  the  next  section,  this  detailed  description  of  the  candidate  system  will 
be  used  to  evaluate  its  key  reliability  characteristics. 

3.4  Reliability  Evaluation  of  Candidate 

The  candidate  system  performs  functions  that  greatly  enhance  the  mission 
effectiveness  of  an  advanced  fighter.  Two  key  measures  were  established 
for  this  system  to  address  the  reliability  specifications  presented  in 
section  3.1.  The  first,  safe  flight  and  landing  (SFL) , is  a measure  of  the 
safety  implications  of  the  system  design.  Safe  flight  and  landing 
capability  means  that  the  aircraft  can  fly  to  a recovery  airfield  and  land 
safely.  Aircraft  operation  may  require  the  use  of  emergency  procedures  and 
diversion  to  an  emergency  base.  This  reliability  measure  is  based  on  a 3- 
hour  period,  which  is  representative  of  a long-deployment  mission. 

The  second  measure,  full  mission  capability  (FMC),  indicates  the  ability  of 
the  aircraft  to  complete  its  mission.  Full  mission  capability  means  that 
the  aircraft  can  continue  to  fly  any  of  its  possible  missions  after  the 
failure  of  a system  element.  The  applicable  redundancy  management  process 
must  automatically  perform  any  necessary  reconfiguration  so  that  continued 
operation  requires  no  special  procedures  and  no  significant  performance 
degradation.  A 1-hour  time  period  consistent  with  a combat  mission  is  used 
for  numerical  evaluation. 

A key  study  assumption,  implicit  in  most  reliability  evaluations,  is  that 
all  significant  elements  are  fully  operational  at  the  start  of  the  mission. 
This  implies  that  preflight  system  tests,  necessary  to  guarantee  correct 
operation  of  all  critical  system  elements,  are  implemented.  Creation  of 
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these  tests  is  another  challenging  task  for  flight-critical  systems.  Most 
successful  approaches  for  ensuring  integrity  before  flight  rely  heavily  on 
the  redundancy  management  processes  designed  for  use  during  flight. 
Preflight  test  definition  has  not  been  addressed  in  this  study. 

The  reliability  evaluation  process  was  accomplished  in  three  phases.  The 
first  phase  is  a functional  failure  analysis,  undertaken  to  define  hov  the 
system  fails.  Next,  an  abstract  model  of  the  resulting  failure  behavior  is 
formulated  and  converted  for  input  to  a reliability  tool.  Finally,  the 
system  loss  probabilities  are  numerically  computed  and  evaluated  to 
understand  the  particular  system  concept's  strengths  and  weaknesses.  The 
failure  analysis  phase  is  described  next. 

The  candidate  system  operation  must  be  analyzed  to  understand  how  the 
system  fails.  A combination  of  top-down  and  bottom-up  techniques  was  used 
in  the  failure  analysis.  Top-down  techniques  were  used  to  classify  and 

group  the  failure  conditions  at  different  levels  of  the  organization 
hierarchy.  Bottom-up  techniques,  based  on  failure  mode  effects  analysis, 
were  used  to  identify  the  effects  of  an  element  failure  on  the  next  higher 
level  of  system  organization.  As  mentioned  earlier,  the  two  system-level 
failure  conditions  of  interest  are  loss  of  SFL  capability  and  loss  of  FMC 
capability. 

The  flight  control  portion  of  the  system  performs  the  functions  organized 
into  the  functional  blocks  illustrated  in  figure  3.4-1.  Similarly,  the 
propulsion  control  functional  blocks  for  one  of  the  two  systems  are 
presented  in  figure  3.4-2.  The  top-down  technique  determined  the 

significant  operational  states  of  these  functional  blocks  by  relating 
system  performance  after  failures  within  the  blocks  to  the  two  system 
failure  conditions  of  interest.  The  goal  is  to  identify  those  functional 
block  states  which  by  themselves  or  in  combination  with  the  states  of  other 
blocks  leads  to  a loss  of  system  capability. 

The  functional  blocks  were  used  to  organize  the  system  elements  for  the 
failure  analysis.  Specifically,  each  element  was  assigned  to  a functional 
block  based  on  its  primary  function.  Each  element's  failure  effect  is 
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Figure  3.4- 1.  Flight  Control  Functions 
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determined  by  the  resulting  operational  state  of  the  functional  block.  The 
process  then  can  relate  an  element  failure  and  the  resulting  redundancy 
management  action  to  an  effect  on  the  system  operational  capability  through 
the  state  of  the  functional  block. 

The  failure  effect  ultimately  depends  on  how  the  element  is  used  by  the 
major  control  functions  and  the  element  failure  mode.  The  basic  failure 
mode  assumed  in  the  analysis  is  loss  of  element  function.  The  failure 
analysis  also  considers  possible  active  failure  modes  to  see  if  any  can 
have  a more  serious  effect  on  the  system.  Any  significant  failure  modes 
were  included  in  the  reliability  models.  The  failure  analysis  must  also 
consider  the  performance  of  the  redundancy  management  process  that  handles 
the  affected  element.  The  current  operating  configuration  is  usually 
important  to  the  performance  of  the  redundancy  management.  These  processes 
can  perform  imperfectly,  failing  to  detect  certain  faults  and  incorrectly 
diagnosing  others. 

3.4.1  Flight  Control  Group  Failure  Analysis 

The  failure  analysis  for  elements  in  the  flight  control  sensing  functional 
blocks  was  based  on  some  standard  assumptions  and  groundrules.  The  voting 
processes  used  for  sensor  redundancy  management  were  assumed  to  operate 
perfectly.  This  means  that  no  false  alarms,  missed  alarms,  or  incorrect 
identifications  occur  as  long  as  good  sensors  outnumber  bad  sensors.  Vhen 
only  two  sensors  remain  (four  for  skewed  sensors),  it  is  assumed  that  the 
process  can  detect  that  a failure  has  occurred  but  cannot  identify  which  of 
the  remaining  sensors  is  bad. 

For  safety-critical  sensing  elements,  it  is  assumed  that  when  the 
redundancy  level  supports  failure  detection  only,  a subsequent  sensor 
failure  causes  loss  of  safety.  However,  in  the  same  situation,  if  the 
subsequent  failure  is  loss  of  data  due  to  a known  communication  failure, 
the  assumption  is  that  safe  operation  continues  using  the  remaining  sensor. 
Of  course,  loss  of  good  data  from  the  final  sensor  causes  loss  of  the 
aircraft . 
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The  assumed  operating  rules  for  most  of  the  mission-critical  sensing 
elements  are  slightly  different.  When  data  are  lost  or  unreliable,  the 
affected  function  can  be  terminated  with  no  affect  on  aircraft  safety. 
Therefore,  when  there  are  only  enough  sensors  to  support  detection,  it  is 
assumed  that  the  function  is  deactivated  when  the  sensor  fails.  In  the 
same  situation,  if  data  from  one  sensor  becomes  unavailable  due  to  a known 
communication  failure,  function  deactivation  is  also  assumed.  Full  mission 
capability  is  lost  when  deactivation  occurs,  but  the  policy  prevents 
hazardous  operation  resulting  from  mission-critical  sensing  failures. 

One  aspect  of  redundancy  management  operation  considered  deals  with  the 
time  required  to  identify  a failed  sensor  and  reconfigure  the  algorithm 
accordingly.  A possible  hazard  exists  if,  during  a sensor  failure  recovery 
period,  another  sensor  from  the  redundant  set  fails.  This  situation  will 
be  referred  to  as  nearly  coincident  sensor  failure.  In  the  case  of  a 
quadruple  set  of  sensors,  it  means  that  two  good  sensor  values  will  be 
processed  with  two  bad  values.  The  resulting  inability  to  "outvote"  the 
bad  data  is  assumed  to  lead  to  the  use  of  bad  data  by  the  system.  For  a 
safety-critical  function,  this  means  loss  of  SFL  capability.  The  results 
in  section  3.4.4  show  that  the  likelihood  of  this  situation  is  very  small 
and  therefore  significant  only  for  the  safety-critical  sensors. 

The  results  of  the  failure  analysis  by  functional  block  are  presented  in 
table  3.4. 1-1  for  the  flight  control  group  of  elements. 


Flight  Control  Sensing 

The  pilot  command  sensing  functional  block  includes  the  pitch,  roll,  and 
yaw  command  sensors  as  well  as  the  flap  lever  and  trim  command  switches. 
Only  the  flight  path  command  sensors  are  safety  critical,  the  rest  are 
mission  critical.  Nearly  coincident  like  sensor  failures  are  a hazard  for 
the  flight  path  command  sensors.  The  standard  ground  rules  apply  to  the 

elements  in  this  block. 
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Table  3. 4.1-1.  Function  Failure  Analysis  - Flight  Control 


Function 

Total  loss 
effect 

Active  failure  mode  considerations 

Pilot  command 

Pitch,  roll,  yaw,  sensing 

Unsafe 

Trim  command  sensing 

SFL 

Flap  lever 

SFL 

Body  motion  sensing 

Rate  sensing 

Unsafe 

Acceleration  sensing 

Unsafe 

Air  flow  sensing 

Angle  of  attack 

Unsafe 

Angie  of  sideslip 

Unsafe 

Static  pressure 

SFL 

Total  pressure 

SFL 

Total  temperature 

- 

Wing  acceleration  sensing 

SFL 

Total  loss  of  capability  during  critical  phase  of  flight  is 
catastrophic 

Flight  control  computing 

Unsafe 

Canard  control 

Unsafe 

Loss  of  single  surface -SFL  (if  all  primary  surfaces 
operational) 

Surface  stuck/jammed  - Unsafe 

Flaperon  control 

Unsafe 

Loss  of  single  surface  or  two  sym  metrical  surfaces  - SFL 
(if  other  primary  surfaces  operational) 

Surfaced  stuck/jammed  - Unsafe 

Rudder  control 

Unsafe 

Loss  of  single  surface  - SFL  (if  all  primary  surfaces 
operational) 

Surface  stuck/jammed  - Unsafe 

TE  flap  control 

SFL 

Loss  of  single  surface  - SFL 

Nosewheel  control 

SFL 

LE  flap  control 

SFL 
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The  body  rate  sensors  and  the  body  acceleration  sensors  are  included  in  the 
body  motion  sensing  functional  block.  It  is  assumed  that  the  redundancy 
management  can  identify  failures  perfectly  as  long  as  five  or  more  sensors 
are  being  used.  Detection  is  possible  only  when  four  sensors  are 
operating;  however,  operation  can  continue  with  three  sensors  if  data  is 
lost  due  to  a known  communication  failure.  Because  dual  simultaneous 
failures  can  theoretically  be  identified  with  seven  or  more  sensors,  nearly 
coincident  sensor  failures  are  not  a concern  with  the  assumed  complement  of 
eight  instruments. 

The  airflow  sensing  functional  block  includes  the  angle  of  attack,  angle  of 
sideslip,  static,  and  total  pressure  sensors.  The  angle  of  attack  and 
angle  of  sideslip  sensors  are  safety  critical  while  the  static  and  total 
pressure  sensors  are  mission  critical.  The  safety-critical  sensors  are 
vulnerable  to  nearly  coincident  sensor  failure  situations. 

The  wing  acceleration  sensing  block  includes  the  wing  accelerometers  at  six 
wing  sites  used  by  the  flutter  control  major  function.  The  fault  reaction 
for  flutter  control  devices  is  slightly  different  from  that  assumed  for 
other  mission-critical  elements.  Flutter  control  allows  high-speed,  low- 
altitude  ingress  with  external  stores.  The  capability  is  needed  for  only 
part  of  some  mission  scenarios.  However,  if  the  aircraft  is  operating  in 
the  critical  part  of  its  flight  envelope,  total  loss  of  this  function  will 
cause  loss  of  aircraft.  Flutter  control  is  different  from  the  other 
mission  critical  functions  in  that  it  cannot  be  immediately  deactivated. 
The  aircraft  must  fly  out  of  the  critical  region  before  the  function  can  be 

turned  off. 

A major  analysis  assumption  is  that  the  flutter  control  law  design  is 
constrained  to  drastically  lower  the  failure  protection  requirements  for 
sensing  and  actuation.  The  specific  design  objective  is  to  provide  a 
minimum  safe  level  of  performance  when  sensing  at  a single  site  or 
actuation  of  a single  surface  is  lost.  The  resulting  degraded  performance 
with  a single  passive  surface  or  a loss  of  sensing  at  one  location  must  be 
adequate  to  allow  safe  flight  out  of  the  critical  flutter  envelope. 


67 


Vith  this  constraint,  flutter  sensing  needs  can  be  met  with  triple 
redundant  sensors  at  each  site,  providing  fail-operational/fail-off 
capability.  The  operating  assumption  is  that  the  aircraft  will  slow  down 
out  of  critical  envelope  before  flutter  control  is  deactivated.  Full 
operation  continues  after  the  first  sensor  failure,  when  only  two  good 
sensors  remain  at  a site.  If  one  of  the  two  remaining  sensors  fail,  data 
from  that  site  is  not  used  while  the  aircraft  slows  down.  After  slowdown, 
the  flutter  control  function  is  deactivated.  Aircraft  slowdown  and  function 
deactivation  is  also  assumed  if  sensor  data  becomes  unavailable  due  to  a 
known  communication  failure.  This  fault  reaction  will  prevent  flutter 
control  operation  with  a single  sensor,  thus  precluding  exposure  to  a 
subsequent  fault  with  catastrophic  effects. 

The  control  law  performance  tradeoffs  associated  with  this  design 
constraint  were  not  evaluated  because  control  law  design  and  analysis  is 
not  a part  of  this  study.  If  it  is  impractical  to  design  a control  law  to 
this  constraint,  there  will  be  an  additional  safety  hazard  with  the 
candidate  architecture  if  flutter  control  operation  is  continued  after 
sensor  failure  (or  surface  actuator  channel  failure).  This  additional 
hazard  was  not  quantified  during  this  study. 

These  assumptions  on  system  behavior  after  sensor  failures  mean  that  except 
for  nearly  coincident  faults,  three  similar  sensing  failures  must  occur 
before  SFL  capability  is  affected.  Similarly,  FMC  capability  is  not  lost 
until  two  like  failures  have  occurred. 

Plight  Control  Computing 

The  major  flight  control  functions  all  have  computing  subfunctions 
performed  in  the  FTP.  The  flight  control  computing  functional  block 
includes  all  of  these  subfunctions.  Manual  control,  needed  for  SFL 
capability,  is  the  most  critical  flight  control  function  dependent  on  the 
FTP.  Because  FTP  throughput  performance  is  not  dependent  on  channel 
redundancy  level,  all  functions  will  continue  execution  after  channel 
faults  until  safe  operation  is  impossible.  Therefore,  the  flight  control 
computing  functional  block  remains  fully  operational  after  most  FTP  channel 
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fsilurGS*  Exact  agreement  of  channel  outputs  can  only  detect  faults  when 
two  FTP  channels  remain.  Thus,  the  final  FTP  channel  failure  occurs, 
causing  all  functions  to  fail  when  there  are  only  two  channels  operating. 

There  were  a couple  of  worst  case  FTP  channel  failure  mode  possibilities. 
Worst  case  computation  failure  modes  would  result  from  events  or  faults 
that  could  affect  correct  computation  in  more  than  one  channel;  however, 
because  avoidance  of  these  situations  is  a key  FTP  design  goal,  they  were 
not  considered  further  in  this  analysis.  In  another  failure  scenario,  an 
FTP  channel  could  fail,  generating  valid  but  incorrect  messages  to  the 
flctu&Cor  interfaces  on  one  of  the  two  networks.  In  this  situation,  an 
actuator  force  fight  will  occur  due  to  the  disagreement  between  the  good 
commands  on  one  network  and  the  bad  commands  on  the  other.  It  was  assumed 
that  the  system  could  tolerate  this  situation  for  one  or  two  application 
cycles.  Furthermore,  it  was  assumed  that  all  such  failures  would  be 
detected  and  full  operation  restored  within  this  time  period.  Thus,  no 
active  computation  failure  modes  were  modeled. 

Flight  Control  Actuation 

The  common  ground  rules  and  assumptions  used  for  flight  control  actuation 
will  be  presented  before  the  specifics  of  each  functional  block.  The 
flight  control  devices  include  the  primary  surfaces  used  in  basic  flight 
path  control,  canards,  flaperons,  and  rudders.  Flight  control  secondary 
devices  include  the  nosewheel  and  the  leading  and  trailing  edge  flaps.  The 
primary  control  surfaces  are  used  by  the  safety  critical  manual  control 
function.  A key  failure  analysis  assumption  is  that  continued  safe  flight 
and  landing  is  possible  if  a single  primary  surface  fails  passively.  For 
roll  axis  control,  it  is  assumed  that  symmetrical  pairs  of  flaperons  can  be 
lost.  In  these  situations,  the  performance  reduction  caused  by  the  loss  of 
a single  surface  takes  away  FMC  capability.  Another  key  assumption  is  that 
failures  that  leave  any  primary  control  surface  stuck  or  hardover  causes 
loss  of  safety. 


Most  actuator  control  element  failures  are  handled  by  the  local  redundancy 
management  processes.  One  assumption  is  that  control  valve  and  hydraulic 
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power  failures  are  perfectly  identified  by  the  local  process  resulting  in 
an  operational  surface  using  the  redundant  devices.  The  remaining 
actuation  elements  have  uncovered  failure  modes  that  cause  the  central 
actuator  management  process  to  command  passive  operation  of  the  device.  A 
worse  surface  failure  mode  occurs  when  a failure  leaves  a device  in  a 
jammed  or  stuck  position.  One  cause  is  a rare  mechanical  jam  failure  mode 
of  the  hydraulic  power  ram.  Other  combinations  of  failures  can  also  lead 
to  this  situation.  The  failure  effect  on  system  capability  of  a jammed  or 
stuck  actuator  is  device  specific. 

Generally,  passive  device  operation  eliminates  FMC  capability,  but  safe 
flight  and  landing  is  still  possible.  For  example,  loss  of  high  lift  or 
nosewheel  steering  may  require  diversion  to  an  alternative  base,  but 
landing  is  possible  using  emergency  procedures.  Similarly,  a passive 
flaperon  will  degrade  the  aircraft  roll  response  below  FMC  standards,  but 
will  allow  a safe  landing.  A summary  of  these  assumptions  is  that  covered 
actuation  element  failures  will  result  in  full  operational  capability, 
while  uncovered  failures  will  lead  to  central  safing  action  and  a 
corresponding  loss  of  FMC  capability. 

The  special  fault  reaction  considerations  for  flutter  control  have  been 
previously  described.  For  actuation,  the  assumption  is  that  the  control 
law  is  designed  with  the  capability  to  fly  out  of  the  critical  flutter 
envelope  with  a single  passive  flutter  control  surface.  Fault  reaction 
will  take  place  if  a flaperon  or  trailing  edge  flap  fails  passive  for  any 
reason  during  flutter  operation.  The  flutter  control  function  will  be 
deactivated  after  the  aircraft  slows  down  out  of  the  critical  flight 
envelope. 

The  canard  control,  flaperon  control,  and  rudder  control  functional  blocks 
include  all  eight  primary  control  surfaces.  The  standard  operating 
assumptions  apply  to  these  surfaces.  Passive  operation  of  a single  surface 
results  in  loss  of  FMC  capability.  SFL  capability  is  lost  if  any  two 
primary  surfaces  are  passive  (except  for  symmetrical  flaperons).  Jam  of 
any  primary  control  surface  is  assumed  to  prevent  safe  flight  and  landing. 
The  flaperon  control  blocks  are  subject  to  the  special  fault  reaction 
considerations  when  flutter  control  is  active. 
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The  nosewheel  control  and  leading  edge  flap  functional  blocks  include  a 
dual-channel  actuation  device  for  each  function.  Passive  operation  of 
either  device  results  in  a loss  of  FMC  performance.  The  leading  edge  flaps 
are  assumed  to  remain  in  their  last  commanded  position  during  passive 
operation.  It  is  assumed  that  a safe  emergency  landing  can  be  accomplished 
with  a jam  of  the  nosewheel. 

The  trailing  edge  flap  functional  blocks  include  the  two  trailing  edge 
surfaces  and  dual-channel  actuator  devices.  A passive  trailing  edge  flap 
results  in  a loss  of  FMC  capability.  Additionally,  if  the  failure  occurs 
during  flutter  control  operation,  the  special  flutter  fault  reaction 
operation  is  required.  Jam  of  either  trailing  edge  flap  results  in  a loss 

of  FMC  capability. 

3.4.2  Propulsion  Group  and  Common  Device  Failure  Analysis 

Before  discussing  the  propulsion  control  elements,  the  capabilities 
provided  by  the  propulsion  system  will  be  evaluated.  The  most  critical 
capability  is  control  of  thrust  adequate  to  support  safe  flight  and 
landing.  For  the  candidate  twin-engine  aircraft,  a certain  level  of 
single-engine  performance  is  assumed  to  be  necessary.  The  remaining 
propulsion  system  capabilities  primarily  support  the  advanced  fighter 
missions;  for  example,  the  variable  inlet  is  necessary  for  supersonic 
missions,  and  the  vectoring  and  reversing  nozzles  support  short  takeoff  and 
landing,  enhanced  supersonic  maneuvering,  and  other  mission  capabilities. 

The  capability  of  each  propulsion  system  after  failures  can  be  divided  into 
three  major  performance  categories:  full,  normal,  and  low  capability.  Full 
capability  means  that  all  functions  are  fully  operational;  this  includes 
full  supersonic  inlet  control;  full  afterburner  thrust  control  and  full 
thrust  vector,  and  thrust  reverse  capability.  The  normal  capability 
category  allows  some  degradation  from  the  full  performance  level.  As  a 
minimum  requirement,  the  engine  must  be  capable  of  providing  the  full 
unaugmented  thrust  range.  The  nozzle  and  the  inlet  can  be  operating  in  a 
fixed  position  mode.  In  the  low  capability  category,  the  system  cannot 
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meet  the  normal  category  minimum  requirements.  The  engine  has  either 
suffered  a serious  malfunction  and  cannot  be  operated,  or  it  can  only  run 
at  a fixed  thrust  level. 

The  performance  levels  of  both  systems  must  be  considered  together  in  order 
to  determine  vehicle  capability.  To  fly  all  of  the  mission  scenarios 
envisioned  for  the  advanced  fighter,  both  engines  must  have  full 
performance  capability.  Full  mission  capability  is  lost  when  either  system 
suffers  a failure  reducing  its  capability  below  full.  Based  on  the  initial 
discussion,  safe  flight  and  landing  capability  is  provided  if  one  of  the 
systems  has  at  least  normal  capability.  Safe  flight  and  landing  capability 
is  lost  when  a failure  occurs  that  results  in  both  systems  having  less  than 
normal  performance  capability.  An  argument  could  be  made  for  requiring 
afterburner  capability  for  single-engine  operation;  however,  this  more 
restrictive  ground  rule  was  not  used  in  this  analysis. 

The  propulsion  control  system  moves  several  devices  to  provide  its 
capabilities.  If  sensing  or  actuation  failures  disable  the  control 
function,  some  of  these  devices  are  assumed  to  have  safe  positions  that 
allow  continued  operation  with  degraded  performance.  These  assumptions  are 
indicated  in  table  3. 4. 2-1  along  with  the  consequences  of  this  fixed 
operation.  These  consequences  are  used  in  the  detailed  failure  analysis. 

Table  3. 4. 2-2  presents  the  results  of  the  failure  analysis  of  the 
propulsion  control  elements  for  a single  engine.  The  total  loss  effect  is 
expressed  in  terms  of  the  single  propulsion  system  capability.  The  next 
column  summarizes  any  special  failure  considerations  for  that  functional 
block.  The  rest  of  this  section  will  discuss  these  results  in  more  detail. 

Propulsion  Sensing 

The  inlet  sensing  functional  block  includes  the  three  sensor  types  needed 
to  support  variable  inlet  operation.  The  mission-critical  inlet  operation 
occurs  only  during  transonic  and  supersonic  flight.  The  inlet  sensor 
redundancy  management  is  based  on  the  inlet  flow  model.  The  inlet  model  is 
assumed  to  allow  perfect  identification  of  the  first  inlet  pressure  sensor 
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Table  3.4.2- 1 . Fixed  Propulsion  Device  Operation 


Device 

Fixed  position 

Consequences 

Upper  ramp 

Subsonic 

Limited  supersonic  capability 

Inner  ramp 

Subsonic 

Limited  supersonic  capability 

Bypass  ring 

Subsonic 

Limited  supersonic  capability 

Fan  guide  vanes 

Run 

Limited  thrust 
Range/reduced  accel/decel 

Compressor  guide  vanes 

Run 

Limited  thrust 
Range/reduced  accel/decel 

Mam  fuel  metering 

Off 

Engine  shut  down 

Afterburner  fuel  metering 

Off 

No  afterburner  capability 

Convergent  nozzle 

Minimum  area 

No  afterburner  capability/ 
reduced  accel/decel 

Thrust  vectoring  nozzle 

Centerline  thrust 

No  vectored  thrust  capability 
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Table  3 4 2-2  Function  Failure  Analysis  - Propulsion  Control  Loss  Effect 


p?$r  <«»'« 


inlet  sensing 


Duct  static  pressure 


Normal  shock  static  pressure 


Normal  shock  static  pressure 


Fan  face  sensing 


Fan  face  pressure 


Fan  face  temperature 


Engine  core  sensing 


Fan  speed 


Compressor  speed 


Burner  pressure 


Fan  turbine  inlet  temperature 


Afterburner  pressure 


Throttle  command  sensing 


Propulsion  computing 


inlet  control 


Upper  ramp 


Inner  ramp 


Bypass  ring 


Vane  control 


Fan  guide  vane 


Compressor  guide  vane 


Main  fuel  control 


Metering  valve 


Flowmeter 


Fuel  shutoff 


A/8  fuel  control 


Zone  metering  valve 


Zone  fuel  shutoff 


Light  off  detector 


Nozzle  control 


Lower  flap 


Upper  flap 


Convergent  nozzle 


Normal 

(SFL) 

Active  failure  mode  requires  engine  shutdown 

Normal 

(SFL) 

Active  failure  mode  requires  engine  shutdown 

Normal 

(SFL) 

Active  failure  mode  may  cause  overspeed  or 
compressor  stall 
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failure  and  perfect  detection  of  the  second  like  sensor  failure.  This 
allows  the  inlet  to  remain  fully  operational  after  the  first  failure. 
Without  the  inlet  flow  model,  failures  cause  fixed  subsonic  inlet  operation 
and  a corresponding  loss  of  FMC  capability. 

The  fan  face  pressure  and  temperature  sensors  are  covered  by  the  fan  face 
sensing  functional  block.  These  sensors  are  used  throughout  the  full 
engine  operating  range.  Detection  and  identification  of  failures  is  also 
accomplished  with  the  inlet  model.  The  redundancy  management  is  assumed  to 
operate  perfectly  while  the  inlet  model  is  operational.  When  sensor  data 
is  not  available  due  to  a dual  like  sensor  failure  or  loss  of  inlet  model 
capability,  the  engine  reverts  to  fixed-thrust  level  operation.  This 
reduces  capability  to  the  low  performance  level. 

The  engine  core  sensing  includes  the  fan  and  compressor  speed  sensors,  the 
burner  and  afterburner  pressure  sensors,  and  the  fan  turbine  inlet 
temperature  sensor.  The  engine  core  sensors  are  critical  to  normal 
performance.  Failures  are  detected  and  identified  using  analytic 
redundancy  techniques.  The  process  handles  certain  sensor  failure  modes 
very  easily,  while  other  failure  modes  present  more  difficulty.  A fail- 
operations/fail-off  level  of  failure  protection  is  assumed,  which  means 
that  the  engine  is  fully  operational  with  the  loss  of  one  sensor  type. 
When  two  sensor  types  are  lost,  the  assumed  fault  reaction  causes  fixed 
thrust  level  operation,  which  is  low  performance  capability. 

The  first  throttle  command  sensor  failure  of  a pair  is  assumed  to  be 
perfectly  identified  with  the  redundancy  management  scheme.  When  the  final 
sensor  of  a pair  fails,  the  engine  reverts  to  low  performance  capability. 
If  the  sensor  failure  is  detected  by  the  process,  fixed-thrust  operation 
results.  If  the  other  throttle  logic  fails  to  detect  the  second  failure, 
the  pilot  can  shut  the  engine  down  for  not  following  commands.  In  either 
case,  the  result  is  a loss  of  normal  performance  capability.  With  these 
operating  assumptions,  it  isn't  necessary  to  distinguish  between  covered  or 
uncovered  second  failures  in  the  reliability  model. 
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Propulsion  Computing 


Propulsion  computing  operates  like  flight  control  computing  in  failure 
situations.  All  computing  functions  are  fully  operational  until  the 
failure  of  one  of  a remaining  pair  of  FTP  channels.  The  assumption  is  that 
redundancy  management  automatically  commands  fixed-thrust  operation  when 
computing  is  lost.  There  may  also  be  a procedural  requirement  to  shut  the 
engine  down  when  conditions  permit.  In  either  case,  performance  is  reduced 
below  the  normal  capability  level. 

Propulsion  Actuation 

Some  standard  assumptions  and  ground  rules  were  used  in  the  failure 
analysis  for  the  propulsion  actuation  functional  blocks.  A common 
propulsion  actuator  was  used  for  all  devices.  The  key  failure  behavior 
assumptions  are  as  follows.  All  but  a fraction  of  the  propulsion  actuation 
element  failures  are  detected  by  the  self-test  processes.  These  covered 
failures  result  in  the  disengagement  of  one  actuator  channel,  but  the 
device  still  has  full  operational  capability  through  the  remaining  channel. 
If  the  remaining  channel  then  suffers  a covered  failure,  disengagement 
causes  the  device  to  move  to  the  preferred  fixed  position. 

Failures  not  detected  by  the  self-test  processes  cause  the  central  actuator 
management  process  to  command  the  propulsion  device  to  the  preferred  fixed 
position.  These  failures  include  undetected  feedback  position  and  actuator 
drive  failures,  as  well  as  a mechanically  jammed  control  valve.  These  are 
single  failure  situations  resulting  in  fixed-device  operation.  Finally, 
the  consequences  of  the  rare  mechanical  jam  of  the  main  actuator  ram  are 
device  specific,  which  will  be  described  in  each  functional  block 
discussion. 

The  inlet  control  functional  group  moves  three  inlet  devices.  If  any  inlet 
device  fails  to  the  preferred  subsonic  position,  both  engines  are  assumed 
to  operate  with  limited  supersonic  performance.  Full  mission  capability  is 
lost  because  this  eliminates  the  ability  to  perform  some  of  the  aircraft 
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missions* 


The  jam  failure  mode  could  leave  an  inlet  device  in  the 
supersonic  position.  This  is  assumed  to  lead  to  reduced  thrust  capability 
at  slower  speeds  and  therefore  a loss  of  normal  performance  capability. 

The  vane  control  functional  group  includes  both  the  fan  guide  vanes  and  the 
compressor  guide  vanes.  Loss  of  ability  to  move  either  set  degrades  the 
engine  performance  while  allowing  continued  operation.  A conservative 
assumption  is  that  this  degraded  operation  does  not  provide  the  normal 
level  of  performance  for  the  system.  A jam  failure  of  the  device  is 
assumed  to  have  the  same  result. 

The  main  fuel  metering  valve,  the  fuel  pumps  and  the  fuel  flow  meters  are 
included  in  the  main  fuel  control  functional  group.  The  fuel  metering 
valve  moves  to  the  shutoff  position  when  continued  control  is  impossible. 
The  resulting  performance  is  below  the  normal  level,  resulting  in  at  least 
a loss  of  full  mission  capability.  The  main  fuel  flow  model  is  assumed 
perfect  in  detecting  and  identifying  flowmeter  and  actuator  position  sensor 
failures.  Continued  full  operation  is  therefore  possible  after  the  first 
failure  of  either  sensor  type.  The  model  also  is  assumed  to  detect  second 
like  failures.  The  main  fuel  metering  valve  reverts  to  the  fixed  shutoff 
position  when  both  flowmeters  or  both  position  sensors  are  lost.  Because 
of  the  flow  model,  there  are  no  uncovered  metering  valve  position  sensor 

failures. 

The  unlikely  jam  failure  of  the  main  fuel  metering  valve  causes  a safety 
hazard.  In  these  situations,  the  central  actuator  management  commands  a 
shutdown  of  the  engine  through  the  fuel  cutoff  valve.  The  fuel  cutoff 
valve  is  dual  so  that  there  are  two  ways  to  accomplish  shutdown.  A 
significant  active  failure  mode  for  this  device  would  be  uncommanded  fuel 
cutoff.  This  failure  mode  would  of  course  also  lead  to  loss  of  normal 
performance  for  the  system.  The  fuel  pumps  are  sized  to  handle  the 
afterburner  fuel  flow.  Full  operation  is  therefore  assumed  possible  if  one 
pump  fails.  Failure  of  both  pumps  leads  to  engine  fuel  shutdown  and  loss 
of  normal  performance  capability. 
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The  afterburner  fuel  control  functional  group  includes  the  A/B  zone  flow 
metering  valves,  the  zone  flow  fuel  cutoff  valves,  the  light  off  detectors, 
and  the  ignitors.  The  afterburner  is  operated  during  limited  periods  of 
the  flight  scenarios.  The  preferred  fixed  position  for  the  metering  valves 
shuts  off  the  fuel  to  that  zone.  Loss  of  metering  capability  for  any  zone 
is  assumed  to  disable  all  A/B  capability.  An  assumption  is  that  the 
central  actuator  management  process  detects  a jammed  metering  valve  and 
reacts  by  commanding  disengagement  of  the  zone  flow  cutoff  valves.  The 
fault  reaction  also  disables  afterburner  operation  for  the  remainder  of  the 
flight.  The  zone  flow  cutoff  valves  can  be  activated  two  ways  to  allow 
zone  flow.  The  active  failure  mode  of  concern  would  be  uncommanded  opening 
of  the  valves.  This  failure  is  hazardous  only  in  conjunction  with  a stuck- 
open  A/B  fuel  metering  valve.  Because  this  situation  is  a combination  of 
two  rare  failure  modes,  it  was  not  included  in  the  reliability  models. 

Perfect  failure  detection  was  assumed  for  the  light  off  detectors.  Full 
operation  is  possible  as  long  as  one  detector  remains  functional.  If  both 
detectors  fail,  afterburner  control  sequencing  is  impossible,  causing  loss 
of  afterburner  capability.  Similarly,  one  ignitor  will  allow  full 
afterburner  operation.  If  both  fail,  afterburner  capability  is  lost.  In 
all  situations  involving  loss  of  afterburner  capability,  the  system 
performance  is  reduced  to  the  normal  level. 

The  nozzle  control  functional  block  includes  the  thrust  vectoring/reversing 
flaps  and  the  convergent  nozzle.  Fixed  operation  for  the  convergent  nozzle 
is  assumed  to  lead  to  normal  capability  for  the  system  with  no  afterburner 
thrust  capability.  The  assumption  for  a jammed  nozzle  area  device  is  loss 
of  normal  performance  capability. 

Fixed  operation  for  the  vectoring/reversing  flaps  results  in  centerline 
thrust  capability  only.  This  would  reduce  the  engine  capability  to  the 
normal  performance  level.  Because  jammed  vectoring/reversing  flaps  could 
have  a severe  effect  on  attitude  and  speed  control,  the  assumed  fault 
reaction  is  an  engine  shutdown  with  a loss  of  normal  performance 
capability. 
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Couunication  Devices 


All  of  the  major  control  functions  in  the  three  groups  of  the  candidate 
system  depend  on  data  transfer  provided  by  network  operation.  Communication 
device  failures  primarily  affect  sensing  and  actuation  functional  blocks. 
That  is,  their  primary  function  of  sensing  the  environment  or  moving 
actuators  for  the  control  function  is  interrupted  by  the  communication 
failures.  The  following  subsection  presents  details  on  the  consequences  of 
communication  device  failures. 

Table  3.4. 2-3  summarizes  a high-level  failure  effect  study  for  the  elements 
composing  an  I/O  network.  Two  generic  failure  modes  are  considered,  the 
active  mode  generally  having  a more  serious  affect  on  network  operation. 
Communications  device  failures  can  affect  sensors  and  actuators  on  one  DIU, 
a subset  of  the  DIUs,  or  all  of  the  DIUs  on  a network.  The  effect  depends 
on  the  device  failure  mode  and  the  location  of  the  failure  in  the  active 
network.  All  sensors  and  actuators  affected  by  the  failure  are  unusable 
until  network  repair  action  restores  communication.  Communication  failures 
can  have  permanent  as  well  as  temporary  effects  on  system  operation.  When 
elements  like  nodes  or  DIU  links  fail,  it  causes  a permanent  loss  of  the 
sensors  and  actuators  dependent  on  them  for  connection  to  the  system. 

Network  redundancy  management  is  challenging  because  it  is  difficult  to 
identify  specific  failures  with  the  information  available  after  an 
unsuccessful  chain  of  transactions.  Many  of  the  failures  have  similar 
effects  when  observed  from  the  FTP.  Repair  attempts  based  on  the  most 
likely  failure  or  the  most  easily  repaired  failure  are  made  to  localize  the 
problem.  Failure  modes  not  included  in  the  table  exist  that  present 
especially  difficult  problems  to  the  network  redundancy  management. 
Particularly  bad  are  those  that  look  like  other  failures  and  cause  the 
resulting  repair  action  to  come  to  a halt  at  an  inopportune  time  during  the 
repair  sequence.  Current  techniques  to  handle  such  failure  modes  employ 
special  time-consuming  tests  at  each  step  in  the  repair  to  ensure  success. 
These  tests  drastically  increase  the  repair  time  and  must  be  custom 
designed  to  catch  each  and  every  unique  failure  mode. 
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Table  3.4  2-3.  Communication  Device  Failure  Summary 


Device  type 

Fault  type 

Fault  effect 

Repair  action 

Network  node 

Passive 

Loss  of  comm  to  all  downstream 
devices 

Rebuild  network  around  failed 
node 

Active 

Nw  unusable 
Node  does  not  obey 
reconfiguration  command 

Rebuild  network  around  failed 
node 

Network  link 

Passive 

Loss  of  comm  to /from  all 
downstream  devices 

Rebuild  path  around  failed  link 

Active 

NW  unusable  or  loss  of  comm  to 
all  downstream  devices 

Rebuild  path  around  failed  link 

Root  link 

Passive 

NW  unusable 

Switch  to  alternate  root  link 

Active 

NW  unusable 

Switch  to  alternate  root 
link/reconfiqure  old  root  node 
to  disable  ofd  root  link 

Network  interface 

Passive 

NW  unusable 

Switch  to  alternate  root  link 

Active 

— 
NW  unusable 

Switch  to  alternate  root 
link/disable  old  root  link  at  old 
root  node 

DIULmk 

Passive 

Loss  of  comm  to  DIU  and  all 
serviced  devices 

Active 

NW  unusable 

Disable  DIU  link  at  servicing 
node 

DIU 

Passive 

Loss  of  comm  to  DIU  and  all 
serviced  devices 

Active 

NW  unusable 
Actuator 

Command  values  corrupted 
Sensor  values  corrupted 

Disable  DIU  link  at  servicing 
node 
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While  the  network  is  being  repaired,  system  operation  must  continue  using 
the  remaining  accessible  sensors  and  actuators.  This  includes  those 
devices  on  the  remaining  good  network  and  any  devices  that  can  still  be 
reached  on  the  network  with  a failure. 

There  are  several  ways  network  operation  during  network  failure  recovery 
can  cause  system  failure.  The  three  most  significant  have  been  termed  (1) 
temporary  exhaustion,  (2)  nearly  coincident  network-sensor/actuator 
recovery,  and  (3)  nearly  coincident  dual  network  recovery.  Temporary 
exhaustion  failures  occur  when  previous  device  failures  leave  the  system 
without  enough  devices  to  safely  fly  during  a subsequent  network  repair 
period.  This  is  shown  in  figure  3. 4. 2-1  for  the  candidate  architecture 
situation  with  quadruple  sensors.  In  the  scenario  presented  by  the  figure, 
both  sensors  on  one  network  have  previously  failed  to  make  the  system 
vulnerable.  A subsequent  failure  on  the  other  network  will  disrupt 
communications  with  the  remaining  devices,  putting  the  system  out  of 
control  until  the  repair  is  completed.  Normal  operation  is  possible  after 
communications  are  restored,  but  if  the  repair  period  is  too  long,  it  will 
be  too  late  to  save  the  system.  Hence,  the  name  temporary  exhaustion. 

A nearly  coincident  network-sensor  recovery  situation  is  shown  in 
figure  3. 4. 2-2.  Normally,  the  bad  data  from  a faulty  sensor  is  prevented 
from  disturbing  the  system  by  the  voting  redundancy  management  process. 
Because  of  normal  sensor  mismatches,  the  process  needs  time  to  reliably 
exclude  the  faulty  sensor  data  from  further  consideration.  In  this 
coincident  network  recovery  situation,  the  voting  process  is  temporarily 
without  enough  good  sensors  to  outvote  the  faulty  sensor.  Bad  data  is 
assumed  to  propagate  to  the  control  function,  causing  loss  of  safety. 


Surface  actuation  for  the  primary  control  surfaces  is  also  vulnerable  to 
nearly  coincident  network  recovery.  As  a consequence  of  the  dual  network 
configuration,  an  actuation  channel  will  disengage  the  actuator  a few 
cycles  after  losing  command  updates.  Disengagement  is  necessary  to  allow 
the  channels  on  the  other  network  to  provide  control  during  network  outages 
or  communication  device  failures.  The  nearly  coincident  situation  occurs 
when  an  actuator  channel  has  an  undetected  failure  that  is  causing  a force 
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fight  with  the  good  channel  at  the  same  time  a network  fault  occurs.  In 
this  situation,  the  central  actuator  management  fault  reaction  commands  the 
surface  to  passive  operation.  If  a network  fault  interrupts 
communications,  the  safe  command  cannot  reach  the  good  actuator  channel. 
The  channel  with  an  undetected  failure  may  therefore  drive  the  surface 
hardover  when  the  good  channel  disengages  due  to  lost  communications. 

The  final  situation  is  nearly  coincident  dual  network  recovery.  This  is  a 
straightforward  case  in  which  both  networks  undergo  repair  at  the  same 
time.  Because  there  are  only  two  networks,  all  affected  redundant  sensing 
and  actuation  is  lost  during  the  mutual  repair  period.  All  three  of  these 
network  operation  situations  are  assumed  to  lead  to  loss  of  safety  because 
of  the  effect  on  safety-critical  sensing  and  actuation. 


Some  of  the  communication  elements  have  active  failure  modes  that  directly 
affect  sensing  and  actuation  performance.  One  example  from  the  table  is  a 
postulated  active  DIU  failure  mode  that  corrupts  the  actuator  command  while 
satisfying  the  DIU-actuator  protocol.  The  problem  will  be  detected  by  the 
central  actuator  management  process  and  will  result  in  central  safing 
action.  This  significant  active  failure  mode  was  included  in  the 
reliability  models  to  assess  the  possible  hazard. 

Another  significant  communication  failure  mode  would  be  a bad  NI  that 
continues  to  send  valid  messages  containing  outdated  actuator  commands. 
This  would  cause  channels  on  the  bad  network  to  oppose  channels  on  the  good 
network  thereby  freezing  the  surfaces.  However,  it  was  assumed  that  this 
situation  would  be  detected  and  terminated  within  a few  application 
execution  cycles,  and  so  it  is  not  included  in  the  reliability  models. 

Central  Power  Distribution 

Two  central  systems  are  used  extensively  by  elements  of  the  candidate 
architecture:  the  hydraulic  power  distribution  and  the  electric  power 

systems.  In  this  study,  the  details  of  the  secondary  power 
configuration,  which  includes  the  engine,  accessory  drive,  and  emergency 
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power  unit,  were  considered  part  of  basic  airframe  system.  Only  the 
distribution  elements  were  considered  part  of  the  IAPSA  II  system  to  be 
analyzed . 

Hydraulic  power  is  supplied  to  the  actuators  of  both  the  flight  control 
group  and  the  propulsion  control  group  by  two  independent  aircraft 
hydraulic  systems.  All  system  actuators  have  two  control  valves  operating  a 
dual  tandem  power  ram.  Loss  of  one  hydraulic  system  is  assumed  to  result  in 
a passive  loss  of  one  of  the  two  hydraulic  channels.  All  actuators  can 
continue  full  operation  with  the  remaining  channel.  If  both  hydraulic 
channels  fail,  all  control  devices  fail  passive,  resulting  in  loss  of  the 

aircraft. 

There  are  many  two-failure  situations  leading  to  a passive  loss  of  an 
actuation  device.  The  loss  of  a hydraulic  system  makes  all  devices 
vulnerable  to  a failure  in  the  other  actuator  channel.  The  actuator 
redundancy  management  processes  must  operate  correctly  during  hydraulic 
system  failures  or  anomalous  performance  situations  that  might  occur  during 
peak  demand  periods  or  operation  after  loss  of  one  system.  For  this 
evaluation,  it  was  assumed  that  actuator  redundancy  management  performs 
perfectly  and  that  hydraulic  failures  lead  to  passive  channel  failures. 

The  electrical  power  distribution  for  the  architecture  was  based  on  an 
approach  for  fault-tolerant  electric  power  presented  in  reference  C. 
Critical  power  is  provided  to  the  IAPSA  elements  through  four  electrical 
load  management  centers.  The  candidate  architecture  assumption  is  that  each 
system  element  is  connected  to  a single  power  source.  It  was  assumed  that 
the  connection  was  organized  so  that  loss  of  a single  power  source  could 
not  reduce  the  redundancy  of  any  sensing,  computing,  or  actuation  device  by 
more  than  one  level.  With  this  assumption,  safety  is  not  affected  by  a 
sequence  of  electrical  source  failures  until  the  loss  of  three  eliminates 
the  computing  function  and  body  motion  sensing. 


There  are  many  three-failure  loss  of  safety  situations  and  two-failure  loss 
of  mission  situations  involving  electric  power  sources.  Because  the 
communication  devices  and  the  dependent  devices  use  the  same  power  source 
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in  a single  connection  system,  redundancy  management  in  the  FTP  sees  the 
effect  of  a power  loss  as  a known  loss  of  communications  with  one-fourth  of 
the  system  devices.  A detailed  electrical  connection  plan  was  not  developed 
for  the  candidate  architecture  analysis.  More  detailed  modeling  of  the 
electric  power  distribution  was  performed  for  the  refined  architecture 
described  in  section  5. 

3.4.3  Reliability  Modeling 

The  functional  block  organization  of  the  system  elements  used  for  failure 
analysis  was  also  used  for  reliability  modeling.  Each  of  the  reliability 
models  covers  a section  of  the  system  containing  key  sensing  or  actuating 
or  computing  elements.  Data  transfer  elements  are  included  in  the  section 
models  where  their  failure  has  a permanent  effect.  Table  3. 4. 3-1  shows  the 
elements  included  in  each  of  the  flight  control  section  models.  The  same 
information  for  the  propulsion  control  elements  on  a single  propulsion 
system  is  presented  in  table  3. 4. 3-2. 

The  reliability  models  are  used  to  estimate  the  likelihood  of  the  failure 
situations  identified  during  the  failure  analysis.  Each  section  model 
includes  the  local  effect  of  hydraulic  system,  electrical  power  system,  and 
network  failures.  The  element  failure  rates  and  other  related  information 
used  in  the  evaluation  are  shown  in  tables  3.4. 3-1  and  -2. 

These  tables  also  show  the  failure  rates  assumed  for  the  system  components. 
Other  parameters  assumed  for  the  reliability  models  are  also  shown  in  the 
tables.  Included  are  the  coverage  values  used  for  the  critical  self-test 
processes  described  in  section  3.4.2.  For  example,  the  self-test  hardware 
is  assumed  to  detect  99  percent  of  the  surface  actuator  position  feedback 
sensor  failures  as  a baseline.  Therefore  1 percent  of  the  failures  lead  to 
undetected  failures  and  a resulting  surface  shutdown.  There  are  also 
entries  for  components  with  significant  active  failure  modes.  In  these 
cases,  the  table  shows  the  fraction  of  total  device  failures  assumed  to  be 
"active"  failures. 

To  simplify  the  reliability  evaluation,  some  conservative  assumptions  were 
made  about  the  temporary  effects  of  network  element  failures.  The  goal  was 
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Table  3.4.3- 1.  Section  Models  - Flight  Control 


Name 

Devices 

Number 

Failure  rate 
(XIO-6/hr) 

Comments 

Cockpit 

Pitchstick  sensors 

4 

10 

Rollstick  sensors 

4 

10 

Rudder  pedal  sensors 

4 

10 

Cockpit  nodes 

4 

15 

Cockpit  DIUs 

4 

15 

Sensors 

Body  rate  gyros 

8 

50 

Body  accelerometers 

8 

30 

Sensor  nodes 

4 

15 

Sensor  DIUs 

15 

Air 

Total  pressure  sensors 

H 

20 

Static  pressure  sensors 

20 

Angle  of  attack  sensors 

■fl 

33 

Angle  of  sideslip  sensors 

33 

Sensor  nodes 

1 

15 

Sensor  DIUs 

WmM 

— 

Fcom 

FTP  channels 

4 

Root  link/root  node 

6 

lip 

NW  interface 

6 

■m 

Pit  (2  surfaces) 

Actuator  processor 

4 

50 

COV  * .95 

Actuator  position  sensor 

4 

10 

COV  = 99 

Valve  drive  group 

8 

- 

Control  valve 

4 

15 

AFF  = 333x10-* 

Canard  DIUs 

4 

37.5 

Canard  nodes 

4 

37  5 

Electrical  load 

Management  center 

4 

20 

Hydraulic  power  supply 

2 

20 

Notes: 

AFF  - active  failure  fraction 
COV  - coverage  fraction 
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Table  3.4. 3-2.  Section  Models  - Propulsion 


Name 

Devices 

Number 

Failure  rate 
(XIO’Mir) 

Comments 

Inlet 

P$D  sensor 

2 

15 

PTns  sensor 

2 

15 

PSNS  sensor 

2 

15 

Inlet  nodes 

2 

37.5 

Inlet  DiUs 

2 

37.5 

AFF  =.  05 

Upper  ramp  actuator 

Inner  ramp  actuator 

1 

Bypass  ring  actuator 

Hi 

Face 

PT2  sensor 

2 

15 

TT2  sensor 

2 

85 

Fan  guide  vane  actuator 

1 

Compressor  guide  vane  actuator 

Engine  nodes 

■fl 

37.5 

Engine  DIUs 

KB 

37.5 

AFF  = .05 

Engine 

N1  sensors 

2 

50 

N2  sensor 

1 

50 

PT4 sensor 

40 

FTIT  sensors 

100 

PT6  sensors 

K 

40 

Engine  nodes 

H 

37.5 

Engine  DIUs 

mm 

37.5 

AFF  = .05 

Fuel 

Main  fuel  metering  actuator 

i 

Fuel  flow  sensor 

2 

40 

Mam  fuel  shutoff 

2 

1 1 

AFF  = .01 

Mam  fuel  pump 

2 

I 

Engine  nodes 

2 

Engine  DIUs 

2 

AFF  =;  05 

Ecom 

FTP  channels 

■■ 

WBsm 

Root  hnk/root  node 

ifl 

NW  interface 

Hi 

Hi 

After 

Zone  fuel  metering  actuator 

5 

Zone  fuel  shutoff  solenoid 

10 

1 1 

AFF  - .01 

A/0  lightoff  detector 

2 

5 

Engine  nodes 

2 

37.5 

Engine  DIUs 

2 

37  5 

AFF  = 05 

A/B  ignitors 

2 

80 

Nozzle 

Upper  flap  actuator 

1 

tower  flap  actuator 

1 

Convergent  actuator 

1 

Nozzle  nodes 

2 

37  5 

Nozzle  DiUs 

2 

37.5 

AFF  = 05 

Prop 

Fail  passive  electronics 

15 

COV  = 99 

Actuator  position  sensor 

10 

COV  = 99 

Control  valve 

15 

AFF1  - .0333 

AFF2  * .333  x IQ-4 

Engage  solenoid 

2 

11 

AFF  * .01 

Notes: 


1 Control  valve  jam  AFF  - active  failure  fraction 

2 Power  ram  jam  COV  - coverage  fraction 
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to  use  the  evaluation  results  to  indicate  potential  problems  with  the 
network  operation.  All  network  element  failures,  regardless  of  failure 
mode,  were  assumed  to  cause  loss  of  all  devices  on  the  entire  network 
during  the  repair  period.  To  scope  the  hazard,  it  was  assumed  that  all 
repair  periods  are  1 second  long. 

A special  failure  analysis  concern  was  the  hazard  associated  with  active 
DIU  failure  modes.  To  assess  the  potential  problem,  a fixed  fraction  of 
all  DIU  faults  were  assumed  to  be  active  failures. 

Two  models  were  created  for  some  of  the  sections,  one  version  to  predict 
the  probability  of  loss  of  flight  safety  and  one  to  predict  the  probability 
of  loss  of  full  mission  capability.  There  were  two  reasons  for  this. 
First,  the  evaluation  tool  only  provides  the  probability  of  reaching  the 
model  absorbing  states  that  correspond  to  either  a loss  of  safety  or  a loss 
of  mission  capability.  Second,  it  turned  out  to  be  more  convenient 
(especially  during  the  refined  configuration  evaluation  effort)  to  build 
separate  models  so  that  failure  condition-peculiar  model  reduction 
techniques  could  be  used. 

The  overall  probability  of  system  failure  was  estimated  by  combining  the 
results  from  the  individually  solved  section  models.  If  the  sections  are 
completely  independent,  the  system  failure  results  from  each  section  are 
added  together  to  provide  a good  first  order  estimate  for  total 

unreliability.  Higher  order  correction  terms  are  missing,  but  the  answer  is 
adequate  for  highly  reliable  systems.  On  the  other  hand,  combining  section 
results  must  be  done  very  carefully  for  the  candidate  system  because  the 
sections  are  not  totally  independent.  Some  of  the  common  elements  affect 
the  state  of  more  than  one  section.  Therefore,  certain  failure  sequences 
appear  in  more  than  one  section  model.  Also,  some  section  failure  states 
need  to  be  considered  together  to  determine  system  success  or  failure.  For 
example,  two  sections  may  have  failure  conditions  with  a level  of 

performance  that  is  not  safety  critical  when  considered  one  at  a time. 
However,  the  coexistence  of  the  degraded  states  in  both  sections  may  result 
in  system  failure.  It  should  be  noted  that  these  kinds  of  problems  can  be 

minimized  by  careful  grouping  of  the  elements  into  sections. 
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The  section  models  were  developed  in  an  iterative  manner  in  the  candidate 
evaluation  effort.  Usually,  the  first  version  of  the  section  model  covered 
just  a few  of  the  failures  and  failure  modes.  A relatively  complete 
section  model  was  built  containing  all  possible  failure  states,  regardless 
of  likelihood.  The  model  was  then  evaluated  and  simplified  to  eliminate 
unimportant  characteristics.  Next,  a more  detailed  version  was  created  by 
adding  more  failure  situations  to  the  model  and  repeating  the  evaluation 
and  simplification  cycle.  Early  in  the  evaluation,  certain  failure 
sequences  were  seen  to  dominate  the  unreliability  of  the  candidate 
configuration.  Because  configuration  changes  were  necessary,  the  analysis 
was  not  carried  to  completion.  Once  it  was  clear  that  the  dominant  failure 
sequences  had  been  determined,  the  modeling  effort  was  terminated.  Some 
specific  points  about  the  resulting  section  models  are  discussed  in  the 
remainder  of  this  section. 

Plight  Control  Models 

The  flight  control  section  models  are  shown  in  table  3. 4. 3-1.  These  models 
were  built  to  evaluate  the  loss  of  safety  failure  conditions,  with  the 
exception  of  the  PIT  model.  During  model  development  and  evaluation,  it 
became  clear  that  the  mission  failure  likelihood  would  be  dominated  by 
single-failure  situations.  Because  none  of  these  were  identified  in  the 
failure  analysis  for  most  of  the  flight  control  functional  blocks,  a 
mission  failure  version  of  the  model  was  not  built. 


The  COCKPIT  model  was  based  on  the  safety-critical  components,  nodes,  and 
associated  DIUs  of  the  pilot  command  sensing  functional  block.  The  model 
captures  sensor  exhaustion  failures,  dependency  on  communication  elements, 
and  nearly  coincident  sensor  failures.  Also  included  were  the  temporary 
exhaustion  and  nearly  coincident  network  recovery  failure  situations. 

The  body  motion  sensing  functional  block  was  evaluated  with  the  SENSOR 
model.  All  of  the  failure  situations  covered  in  COCKPIT  are  included, 
except  for  nearly  coincident  like  sensor  failures.  As  described 
previously,  nearly  coincident  sensor  failures  are  not  a threat  with  eifht 
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devices  until  two  sensors  have  failed.  However,  the  model  includes  the 
nearly  coincident  network-sensor  failure  situation  because  it  is  still  a 
problem. 

The  AIR  model  was  based  on  the  airflow  sensing  functional  block.  This 
model  treated  the  quadruple-redundant  static  and  total  pressure  sensors  as 
though  they  were  safety  critical.  This  was  a conservative  approach  because 
the  defined  manual  control  function  does  not  require  them.  This  inclusion 
had  no  significant  effect  on  the  model  results.  The  model  includes  all  of 
the  failure  situations  covered  in  the  COCKPIT  model. 

Two  FCOM  models  were  built  based  on  the  flight  control  computing  functional 
block.  One  of  the  models  evaluates  the  loss  of  safety  failure  condition. 
Another  model  was  defined  to  evaluate  the  likelihood  of  permanent  loss  of 
either  network.  In  such  a situation,  the  subsequent  failure  of  any  safety- 
critical  sensor  is  catastrophic.  The  evaluation  confirmed  the  assumption 
that  the  permanent  failure  of  a single  network  in  the  candidate  system  was 
not  a part  of  any  of  the  significant  system  failure  sequences. 

The  PIT  model  treated  the  failure  behavior  of  a pair  of  control  surfaces 
based  on  the  canard  control  functional  block.  As  mentioned  previously,  two 
versions  of  PIT  were  built,  one  to  the  safety  criteria  and  one  to  the 
mission  criteria.  The  safety  model  included  the  following  failure 
situations:  (1)  a single  surface  jammed  or  hardover,  (2)  a pair  of  passive 
critical  surfaces,  and  (3)  a dual  hydraulic  failure.  Additionally,  the 
temporary  exhaustion  and  nearly  coincident  actuator-network  recovery 
failure  situations  were  covered.  The  mission  model  only  included  the 
dominant  failure  sequences,  all  of  which  cause  a single  passive  surface. 

The  results  of  these  two  PIT  models  were  extended  to  estimate  failure 
contributions  due  to  the  four  primary  surface  pairs.  A weakness  of  the 
candidate  architecture  results  is  that  the  dual  passive  surface  failure 
situations  did  not  account  for  passive  surface  combinations  on  different 
axes.  For  example,  the  likelihood  of  system  failure  due  to  a passive  canard 
and  passive  flaperon  was  not  calculated.  It  should  also  be  noted  that  the 
contribution  to  mission  failure  from  the  secondary  flight  control  devices 
was  not  evaluated. 


Propulsion  Control  Models 


The  section  models  for  the  propulsion  system  are  shown  in  table  3. 4. 3-2. 
These  models  were  built  to  evaluate  the  likelihood  of  a single  system 
losing  either  full  or  normal  performance  capability.  In  accordance  with 
the  general  failure  analysis  ground  rules  presented  earlier,  loss  of  full 
performance  on  either  engine  causes  loss  of  mission.  Loss  of  vehicle 
safety  occurs  when  both  engines  have  less  than  normal  performance. 
Temporary  exhaustion  situations  are  included  in  many  of  the  propulsion 
control  models  to  quantify  their  likelihood.  It  was  not  clear  whether 
propulsion  control  functions  could  be  designed  to  tolerate  temporary 
exhaustion  situations.  In  any  case,  the  numerical  results  showed  that  such 
failures  were  not  significant.  The  following  discussion  provides 
additional  information  about  the  specific  models. 

The  INLET  model  includes  elements  from  both  the  inlet  sensing  and  inlet 
control  functional  blocks.  Loss  of  full  performance  capability  is  the 
model  failure  condition  because  that  is  the  result  of  most  inlet  element 
failures.  The  model  includes  sensor  and  actuator  channel  exhaustion 
failures  and  dependency  on  communication  elements.  Inlet  device  control 
valve  jams  are  incorporated  as  a significant  active  failure  mode.  Inlet 
device  jams,  leading  to  a loss  of  normal  capability,  are  modeled  and 
visible  in  the  section  results. 

The  inlet  flow  model  was  assumed  to  be  fully  operational  for  redundancy 
management.  Total  loss  of  one  of  the  necessary  sensors  results  in  either 
loss  of  normal  performance  capability  or  fixed-inlet  operation.  In  either 
case  this  means  that  the  flow  model  is  available  when  needed.  The  only 
situation  that  might  violate  the  assumption  is  the  nearly  coincident 

failure  of  two  sensors  covered  by  the  inlet  flow  model.  Because  this 
unlikely  situation  cannot  contribute  significantly  to  system  failure,  it 
was  not  treated  in  the  model. 

The  fan  face  pressure  and  temperature  sensors  from  the  fan  face  sensing 
block  and  the  fan  and  compressor  guide  vanes  from  the  vane  control 
functional  block  are  included  in  the  FACE  model.  This  model  was  built  to 
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evaluate  the  likelihood  of  element  failures  causing  loss  of  normal 
performance  capability.  The  same  failure  situations  included  in  INLET  are 

covered  in  PACE. 

The  ENGINE  model  includes  just  the  engine  sensors  from  the  engine  core 
sensing  functional  block.  The  model  failure  condition  was  loss  of  data 
from  two  or  more  types  of  core  sensors.  This  is  a loss  of  normal 
performance  failure  condition.  ENGINE  also  included  the  nearly  coincident 
sensor-network  recovery  situation  and  temporary  exhaustion  failure 
situation.  In  addition,  ENGINE  modeled  the  likelihood  of  nearly  coincident 
failures  among  the  five  sensor  types. 

Most  of  the  elements  in  the  main  fuel  control  functional  block  are 
contained  in  the  FUEL  model.  The  exception  is  the  dual  fuel  pump  that  was 
modeled  separately.  The  model  failure  condition  was  loss  of  normal 
performance  capability.  One  special  situation  for  this  model  is  that  there 
are  no  undetected  position  sensor  failures  in  the  main  fuel  metering 
actuator.  Also,  active  fuel  shutoff  valve  failures  that  cause  uncommanded 
engine  shutdown  are  modeled. 

FCOM  models  the  behavior  of  a triplex  FTP  that  performs  the  propulsion 
system  computing  for  a single  system.  Two  versions  of  FCOM  were  built. 
The  failure  condition  for  one  version  was  loss  of  normal  performance 
capability.  The  second  version  included  loss  of  a single  network  as  a 
special  failure  condition.  This  version  verified  that  failures  associated 
with  single  network  operation  are  not  significant  contributors  to  system 

failure. 

Most  of  the  elements  from  the  afterburner  fuel  control  functional  block  are 
handled  in  the  AFTER  model.  The  exceptions  are  the  ignitors  and  light  off 
detectors,  which  are  modeled  separately.  AFTER  models  device  failures  that 
cause  the  system  to  lose  full  performance  capability.  This  model  includes 
exhaustion  failures,  dependency  on  communication  elements,  device  jam, 
control  valve  jam,  and  temporary  exhaustion. 
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NOZZLE  includes  the  devices  from  the  nozzle  control  functional  block.  Most 
nozzle  element  failures  reduce  system  performance  to  the  normal  level.  The 
model  includes  nozzle  device  jam  failures  that  lead  to  a worse  condition, 
loss  of  normal  performance.  NOZZLE  contains  all  the  failure  situations 
included  in  the  AFTER  model. 

3.4.4  Reliability  Results 

The  most  important  benefit  of  early  system  evaluation  is  that  it  provides 
indications  of  the  system's  strengths  and  weaknesses.  The  reliability 
results  available  to  the  system  design  team  must  be  detailed  enough  to  be 
used  for  making  improvements.  The  system  failure  probabilities  should  be 
categorized  by  specific  failure  situation  to  assist  the  reliability 
evaluation.  This  information  should  provide  insight  into  the  operation  of 
the  fault— tolerant  system,  which  can  then  be  used  to  guide  necessary  system 
design  changes. 

A fault-tolerant  system  can  fail  in  several  ways.  Redundancy  exhaustion  is 
the  most  obvious  failure  mechanism.  When  enough  of  the  redundant  devices 
fail,  the  function  can  no  longer  operate.  For  highly  reliable  systems, 
imperfect  performance  of  the  redundancy  management  processes  becomes 
important.  In  this  study,  nearly  coincident  like  sensor  failures  were 
identified  as  a cause  of  early  system  failures.  Because  this  failure 
mechanism  is  related  to  the  duration  of  the  failure  recovery  process, 
reliability  modeling  is  necessary  to  specify  a requirement  for  the  system. 
This  study  also  defined  several  failure  mechanisms  involving  operation  of 
the  I/O  network.  The  detailed  results  show  whether  or  not  the  specific 
building  block  configuration  is  satisfactory  for  the  IAPSA  II  system. 

The  design  also  incorporated  elements  that  were  subject  to  postulated  rare 
active  failure  modes  or  failure  modes  that  could  not  be  detected  by  simple 
redundancy  management  processes.  One  evaluation  question  is  whether  the 
simpler,  lower  performance  processes  can  support  the  system  requirements. 
If  not,  more  complicated  hardware  and  software  is  needed.  Therefore,  the 
detailed  results  must  quantify  the  contribution  of  these  special  failures 
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to  system  unreliability.  A complication  is  that  the  input  failure  mode 
data  is  generally  not  available  for  devices  early  in  the  design  process. 
Good  quality  data  of  this  kind  is  usually  the  result  of  detailed  failure 
analysis  of  inservice  equipment  failures. 

Likewise,  failure  data  to  support  the  evaluation  of  the  undetected  failure 
mechanism  is  difficult  to  obtain.  To  determine  good  coverage  values  for 
the  processes  used  in  the  candidate  system  definition,  a full  redundancy 
management  performance  analysis  must  be  performed  using  device  failure 
characteristic  data.  Again,  information  at  this  level  of  detail  is  usually 
not  available  for  early  concept  development  work.  The  approach  taken  for 
this  study  is  to  use  assumed  values  to  indicate  the  magnitude  of  the  threat 
associated  with  the  respective  failure  mechanism.  These  results  must  then 
be  treated  as  having  a much  higher  than  normal  level  of  uncertainty. 

Design  concept  results  containing  sequences  with  a lot  of  uncertainty  must 
be  evaluated  carefully.  Different  designers  will  interpret  the  same 
results  very  differently.  There  are  several  options  available  for  design 
concepts  whose  reliability  is  dominated  by  failure  sequences  with  a high 
degree  of  uncertainty.  One  option  is  early  prototype  development  of  the 
devices  and  redundancy  management  processes  in  question.  Evaluation  of  the 
prototypes  would  provide  accurate  data  for  assessment  and  improvement  of 
their  design  and  performance.  Alternatively,  compatible  design  concepts 
could  be  developed  in  parallel  to  be  available  as  a backup  if  the  original 
concept  turns  out  unsatisfactory  after  undergoing  detailed  development. 
The  program  benefit  of  the  rough  evaluation  of  these  more  complicated 
failure  mechanisms  is  the  early  warning  provided  for  specific  areas  of 
possible  development  risk. 

The  model  results  for  the  loss  of  safe  flight  and  landing  capability  are 
shown  in  table  3. A. 4-1.  The  safety  data  are  based  on  mission  time  of  3 
hours.  The  results  are  divided  into  functional  blocks,  which  show  how  the 
loss  of  specific  functions  contribute  to  the  loss  of  safety.  These  results 
come  from  the  flight  control  models  for  COCKPIT,  SENSOR,  AIR,  FCOM,  and  PIT 
(safety  condition). 
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Table  3. 4. 4-1.  Safety  Reliability 


Functional  block 

Probability  x 10*7 

FC  sensing 

Pilot 

.0023 

Body  motion 

5.08 

Airflow 

.0078 

FC  computing 

.012 

FC  surface  control 

Pitch 

.19 

Roll 

38 

Yaw 

.19 

Hydraulic  power 

.036 

Dual  propulsion  control 

.0076 

Total 

5.9 

The  contribution  to  loss  of  safety  from  the  propulsion  system  was  based  on 
situations  where  failures  cause  one  system  to  have  less  than  normal 
performance  capability.  The  FACE,  ENGINE,  and  FUEL  models  were  evaluated 
for  a 3 hour  period  to  establish  this  probability.  Additionally,  the  small 
contribution  due  to  jam  failures  in  the  INLET  and  NOZZLE  models  was 
included  in  the  single  system  value.  This  value  was  then  used  to  estimate 
the  likelihood  of  the  unsafe  situation  where  both  systems  have  less  than 
normal  performance. 

Before  combining  the  results  from  the  separate  models,  it  was  necessary  to 
eliminate  the  double  counting  of  communication  element  failure  sequences. 
For  example,  the  ENGINE  and  FUEL  models  both  contaian  the  engine 
nodes/DIUs.  Identical  dual  failure  sequences  are  contained  in  both  models. 
The  probability  sums  were  adjusted  where  necessary  so  that  common  sequences 
were  only  counted  once. 

A few  failure  sequences  dominated  the  safety  reliability  for  the  candidate 
architecture,  preventing  it  from  meeting  the  system  requirement.  The 
predominant  sequence  was  loss  of  body  motion  sensing  in  a temporary 
exhaustion  failure  situation.  This  two-failure  sequence  occurs  when  a node 
or  DIU  fails,  leaving  the  system  vulnerable  to  subsequent  repair  on  another 
network.  When  the  subsequent  network  element  failure  causes  the  other 
network  to  shutdown  for  repair,  only  two  good  sensors  are  accessible 
instead  of  the  three  needed  to  estimate  the  three  axis  states.  A key 
assumption  in  temporary  exhaustion  failure  modes  is  that  the  network  repair 
exceeds  the  time  the  system  can  tolerate  loss  of  control.  Another 
assumption  affecting  the  likelihood  of  this  failure  sequence  is  that  all 
network  element  failures  lead  to  a long  repair  period. 

The  other  dominant  loss  of  safety  sequences  are  associated  with  surface 
control.  The  first  situation  is  a jammed  or  stuck  single  surface.  The  two 
most  common  failure  sequences  are  (1)  a mechanical  jam  of  the  power  ram  and 
(2)  a detected  failure-undetected  failure  sequence  in  the  two  actuator 
channels  for  one  surface.  The  second  dominant  surface  control  situation  is 
a pair  of  critical  surfaces  failing  passive.  The  most  common  cause  of  this 
situation  is  an  undetected  actuator  channel  failure  on  one  surface  leading 
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to  central  safe  action,  followed  by  an  undetected  failure  on  a channel  of 
the  second  surface.  It  should  be  noted  that  the  contribution  to  loss  of 
safety  from  passive  pairs  is  understated  in  table  3. 4. 4-1  because  the 
probability  was  calculated  for  pairs  on  the  same  control  axis.  Passive 
surface  pairs  on  different  axes  were  not  included. 

The  element  failure  modes  that  take  part  most  often  in  surface  control 
failure  sequences  are  undetected  actuator  channel  failures  and  mechanical 
jam  failures.  Undetected  failures  include  actuator  processor  or  position 
sensor  faults  not  covered  by  the  local  redundancy  management  as  well  as 
active  DIU  faults.  There  is  a large  uncertainty  associated  with  the 
probability  of  these  failures.  Mechanical  jam  of  the  power  ram,  for 
example,  is  usually  considered  to  fall  in  the  extremely  improbable 
category.  The  other  channel  failures  were  characterized  by  a coverage  and 
active  failure  fraction  in  the  reliability  model.  As  mentioned  earlier, 
these  values  are  not  well  known  early  in  the  system  life  cycle;  however, 
for  the  nominal  values  used  in  this  analysis,  the  surface  control  failure 
sequences  were  significant  to  aircraft  safety. 

The  full  mission  capability  reliability  for  the  system  is  shown  in 
table  3. 4. 4-2.  All  of  the  propulsion  control  models  were  used  in  the 
mission  evaluation.  The  models  were  evaluated  using  a mission  time  of 
1 hour.  Any  failure  reducing  a single  propulsion  system  below  full 
performance  capability  causes  a loss  of  full  mission  capability.  Active 
DIU  failures  were  not  incorporated  directly  in  the  propulsion  control 
models.  The  effect  was  calculated  separately  assuming  that  inlet  and 
nozzle  active  DIU  failures  caused  loss  of  FMC  capability  due  to  fixed 
operation,  while  active  engine  DIU  failures  cause  loss  of  normal 
performance  capability  for  the  engine. 

With  the  exception  of  the  surface  control  devices,  elements  from  the  flight 
control  group  were  not  included  in  the  mission  capability  evaluation.  The 
flight  control  models  described  earlier  covered  safety  critical  elements 
that  lose  mission  capability  at  the  same  time  they  lose  safety.  These 
elements  therefore  don't  affect  mission  reliability  until  the  third 
failure.  Early  evaluation  results  showed  that  only  one  and  two  failure 
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Table  3.4  4-2.  Mission  Capability  Reliability 


Functional  block 

Probability  x 1(H 

FC  surface  control 

Pitch 

.18 

Roll 

36 

Yaw 

.18 

Propulsion  system  (per  engine) 

Fixed  inlet 

046 

Fixed  guide  vanes 

031 

Engine  core  sensing 

00066 

Core  fuel  metering 

016 

Afterburner  metering 

.076 

Fixed  nozzle 

045 

Engine  computation 

0015 

Propulsion  DIU  active  fault* 

.1 1 

Aircraft  total 

1.4 

Notm  models 


sequences  contributed  significantly  to  loss  of  mission  capability  for  the 
candidate  architecture.  Of  all  of  the  flight  control  models  described 
earlier,  only  PIT  had  a loss  of  mission  capability  at  the  one-failure 
level.  Therefore  only  the  mission  capability  version  of  the  PIT  model, 
which  evaluates  the  likelihood  of  a single  passive  surface,  was  used  for 
the  loss  of  mission  capability  evaluation. 

The  mission  success  likelihood  was  unsatisfactory  based  largely  on  failures 
requiring  central  actuator  management  action  to  safe  actuation  devices. 
These  are  all  cases  in  which  full  mission  capability  is  lost  at  first 
failure.  The  specific  failures  consisted  of  active  DIU  failures, 
undetected  actuator  controller  faults,  and  propulsion  actuator  control 
valve  jams.  Like  the  flight  control  actuation  safety  situation,  all  of 
these  failures  are  modeled  with  parameter  values  that  have  a large  range  of 
uncertainty. 

Several  aspects  of  the  candidate  architecture  were  not  completely  modeled; 
however,  the  results  were  carried  far  enough  to  show  the  need  to  change  the 
design  concept  to  better  meet  the  reliability  requirements.  The  key  safety 
concern  is  that  certain  two-failure  sequences  cause  loss  of  capability. 
Similarly,  certain  single  failures  can  cause  loss  of  mission  capability. 
The  specific  situations  and  the  resulting  design  refinements  are  discussed 
in  section  5. 
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4.0 


CANDIDATE  PERFORMANCE  EVALUATION 


This  section  details  the  performance  analysis  of  the  IAPSA  II  candidate 
system  architecture.  The  performance  evaluation  steps  shown  in  figure  4.0- 
1,  are  described  in  reference  5.  An  overview  of  the  key  methodology  steps 
is  presented  in  the  following  paragraphs. 

Application  Performance  Requirements 

Performance  requirements  deal  with  allowable  update  rates  and  time 
parameters  associated  with  the  defined  control  functions.  These 
requirements  were  defined  in  section  3.  After  the  control  functions  have 
been  mapped  onto  an  architecture  configuration,  the  configuration  must  be 
evaluated  to  guarantee  that  the  control  function  performance  requirements 
are  met. 

This  effort  defines  the  digital  implementation  timing  characteristics 
needed  to  satisfy  the  mission  and  safety  requirements.  These  timing 
requirements  include  control  law  update  rates;  allowable  end-to-end  time 
delay  between  sensor  reads  and  resulting  actuator  commands;  and  limits  on 
the  frame-to-frame  variability  of  control  cycle  actions  (jitter). 

Architecture  Description 

The  performance  analysis  is  based  on  an  architecture  description  that 
defines  how  the  timing  of  the  key  application  functions  is  to  be 
controlled.  These  key  sequencing  and  control  details  must  be  defined 
whether  the  architecture  is  based  on  a custom  design  or  on  a building-block 
approach,  such  as  that  used  for  IAPSA  II. 

Synthesize  Candidate  Architecture 

This  step  maps  the  control  functions  onto  the  candidate  configuration  and 
details  the  operation  of  the  sequencing  and  control  functions.  Simple 
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Figure  4.0-1.  Performance  Evaluation  Methodology 
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timing  charts  are  used  to  organize  the  application  computing,  application 
I/O,  and  system  processes.  This  step  may  eliminate  many  configurations 
using  these  simple  timing  charts.  During  this  step  the  underlying  system 
or  executive  functions  may  need  definition  (specification). 

Identify  Critical  Validation  Issues 

In  addition  to  the  normal  performance  requirements,  the  performance  model 
should  be  able  to  be  used  for  early  evaluation  of  any  critical  validation 
issues  related  to  timing.  In  general,  these  include  situations  in  which 
stringent  timing  needs  must  be  met  for  safe  operation  of  the  system. 
Identification  and  evaluation  of  these  issues  early  in  the  system  design 
phase  will  greatly  enhance  the  development  and  validation  effort. 

Define  Experiments 

Experiments  are  defined  for  evaluation  of  the  candidate  under  normal 
performance  and  failed  conditions.  In  addition,  the  critical  validation 
issues  are  investigated.  The  experiment  definition  includes  the  key  input 
and  output  variables,  the  technique  to  control  the  experiments,  and  also 
the  number  of  runs  needed  to  assess  the  statistical  variations  in  the  data. 


Build  Model 

A simulation  model  is  developed  to  investigate  the  critical  system 
behavior.  The  simulation  is  normally  composed  of  high-level,  low-fidelity 
functional  models  of  the  key  application  processes,  together  with  models  of 
the  associated  sequencing  and  control  functions.  The  decision  about  what 
functional  behavior  should  be  included  or  how  much  detail  needs  to  be 
modeled  is  based  on  the  data  needed  to  support  the  defined  experiments. 
The  simulation  can  be  updated  as  the  detailed  design  is  developed.  This 
expanded  simulation  model  can  then  be  used  in  future  development  phases  to 
verify  the  correct  implementation  of  the  hardware  and  software.  Finally, 
the  detailed  simulation  model  can  be  used  as  part  of  the  supporting 
deliverable  data  for  validation. 
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Collect  Data  and  Evaluate 


The  simulation  model  is  used  to  perform  the  experiments  defined  to  study 
normal  performance  and  the  critical  validation  issues.  The  data  results 
are  evaluated  in  terms  of  the  application  performance  requirements.  Based 
on  the  data  evaluation,  four  possible  decisions  can  be  made,  as  shovn  in 
figure  4.0-1:  (1)  reject  the  candidate  architecture,  (2)  accept  the 
candidate  architecture,  (3)  refine  the  architecture,  and  (4)  identify  new 
critical  issues. 

The  candidate  architecture  is  acceptable  when  all  application  performance 
requirements  are  satisfied.  Refinement  actions  modify  the  implementation 
concept,  which  will  require  changes  in  the  simulation  model.  As  a result 
of  the  insight  gained  during  the  evaluation,  new  critical  issues  may  become 
apparent.  This  will  require  changes  in  the  set  of  evaluation  experiments. 
Furthermore,  as  more  detail  of  the  configuration  is  added,  additional 
requirements  will  be  generated. 

The  following  sections  describe  in  detail  how  the  performance  evaluation 
process  was  applied  in  the  IAPSA  II  work. 

4.1  Synthesize  Candidate 

4.1.1  Application  Performance  Requirements 

The  purpose  of  the  IAPSA  II  study  is  the  design  and  validation  of  a control 
system  architecture  for  a twin— engine  fighter  with  significant  coupling 
between  the  airframe  and  engines.  This  section  describes  the  application 
performance  requirements  adopted  for  the  IAPSA  II  reference  configuration. 

The  control  law  design  effort  defines  the  necessary  timing  requirements  for 
each  function.  The  control  function  is  implemented  with  a repetitive 
timing  cycle  that  reads  the  sensors,  updates  the  control  law  variables,  and 
commands  the  actuators.  The  design  effort  defines  the  necessary  update 
rate  needed  for  satisfactory  performance  of  the  control  function.  The 
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fundamental  performance  requirement  is  then  to  perform  all  the  computing 
and  I/O  activity  defined  by  the  design  effort  in  the  available  update 
period. 

The  system  specification  also  requires  that  the  application  activity  have 
100  percent  growth  capability.  In  general,  growth  capability  is  difficult 
to  measure  because  of  the  system  complexity.  In  this  study,  a simple 
measure  of  growth  capability  was  used  indicating  how  much  the  application 
activity  can  increase  before  reaching  system  throughput  limits. 

Control  law  performance  is  affected  by  the  end-to-end  time  delay  between 
the  reading  of  a sensor  and  the  start  of  the  resulting  actuator  movement. 
This  time  delay  interval  is  illustrated  in  figure  4. 1.1-1  for  a specific 
sensor-actuator  pair.  The  effect  of  time  delay  on  control  law  performance 
ranges  from  imperceptible  to  rough  handling  characteristics  to  loss  of 
control  in  extreme  cases.  Specific  performance-related  time  delay  limits 
were  not  available  for  the  IAPSA  II  control  functions;  a time  delay  value 
of  one  control  cycle  period  or  frame  was  assumed  to  be  the  criterion  for 
satisfactory  performance. 

The  control  law  design  is  usually  based  on  a sampled  data  approach  that 
implicitly  assumes  uniform  sampling  periods  (regularity  in  the  control 
cycle  repetition  rate).  The  important  control  cycle  actions  with  respect 
to  lack  of  regularity  or  jitter,  are  the  reading  of  sensors  and  commanding 
of  actuators  (fig.  4. 1.1-1).  As  with  time  delay,  specific  performance 
requirements  were  not  available  for  control  cycle  jitter.  Small  variations 
with  respect  to  the  update  period  are  acceptable,  while  large  variations 
are  unsatisfactory. 

4.1.2  Reference  Configuration  Analysis 

This  analysis  develops  the  high-level  system  performance  data  that  will  be 
used  to  evaluate  the  candidate  architecture.  The  focus  is  on  how  hardware 
and  software  elements  of  the  candidate  architecture  perform  the  application 
functions.  In  this  analysis,  the  performance  of  each  major  group  (flight 
control  and  engine  control)  is  treated  separately.  Ultimately  a separate 
simulation  model  is  created  for  each  group. 
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Figure  4. 1.1-1.  Example  Application  - Update  Rate  100  Hz 
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The  performance  model  was  developed  in  three  distinct,  sequential  phases. 
The  three  phases  were  (1)  the  initial  timing,  (2)  initial  AIPS  timing,  and 
(3)  revised  AIPS  timing.  In  these  phases  the  application  timing  data  are 
built  up  and  organized  manually  using  simple  timing  charts.  Situations 
involving  variable  timing  needs  or  contention  for  shared  resources  are 
deferred  to  the  simulation  model  development  for  promising  configurations. 

4.1.3  Initial  Timing 

The  organization  of  the  application  activity  follows  the  computing 
subfunction  allocation  defined  in  section  3.  All  functions  within  the  same 
update  rate  are  lumped  into  a single  rate  group.  The  computing  and  I/O 
activities  for  all  the  functions  in  the  same  rate  group  are  combined. 
Therefore,  if  more  than  one  function  needs  to  communicate  with  the  same 
DIU,  the  DIU  is  accessed  only  once,  obtaining  all  data  needed  by  the 
functions  in  that  rate  group.  This  consolidation  of  message  traffic 
reduces  the  I/O  demands  of  the  application. 

The  initial  timing  assumes  that  the  control  cycle  for  each  application  rate 
group  starts  with  the  input  I/O  activity  needed  by  the  rate  group,  followed 
by  the  compute  activity,  and  finally  by  all  output  I/O  activity.  This 
particular  organization  of  the  I/O  activity  is  referred  to  as  separated 
I/O.  The  input  I/O  activity  for  each  application  rate  group  supplies  all 
data  from  the  sensors,  actuator  positions,  etc.,  requested  by  all  functions 
during  the  current  control  cycle  update.  The  compute  activity  performs  any 
sensor  and  actuator  redundancy  management  and  updates  the  control  law 
variables.  The  output  activity  consist  of  sending  position  and  redundancy 
management  commands  to  all  the  necessary  actuators  via  the  DIUs.  This 
organization  of  I/O  activity  and  computing  activity  is  shown  in  figure 
4. 1.1-1  for  a single  application  rate  group. 


The  initial  timing  development  phase  considers  a single  I/O  network  that 
must  be  shared  by  all  rate  groups.  The  input  I/O  activity  starts  each 
control  cycle.  I/O  activity  is  nonpreemptable;  once  started  it  runs  to 
completion.  A sequencing  and  control  function  is  assumed  that  operates 
each  rate  group  in  order  of  priority,  with  the  fastest  rate  first. 
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In  contrast  to  the  single  shared  I/O  network,  the  computing  for  each 
application  rate  group  is  assumed  to  have  its  own  dedicated  processor. 
Once  the  input  I/O  activity  for  a rate  group  is  completed,  the  computing 
activity  begins.  At  the  conclusion  of  the  computing  activity  the  control 
function  starts  the  output  I/O  activity.  When  the  output  activity  for  that 
rate  group  is  completed,  the  control  function  starts  the  next  rate  group 
scheduled  for  that  minor  frame.  Note  that  this  assumes  that  a rate  group 
does  not  relinquish  the  network  for  lower  priority  activity  until  the 
completion  of  its  output  I/O  activity.  The  final  control  assumption  is 
that  all  rate  groups  are  scheduled  for  initial  execution  at  the  very  first 
minor  frame. 

The  remaining  initial  model  assumptions  deal  with  the  I/O  activity 
duration.  The  two  major  elements  are  DIU  processing  and  the  duration  of  the 
command  and  response  messages.  The  first  element  to  be  discussed  is  DIU 
processing.  The  system  operates  in  a command-response  mode.  The 
application  rate  group  sends  an  I/O  message  containing  a unique  operation 
code  to  each  DIU  in  sequential  order.  If  appropriate,  the  DIU  returns  a 
response  message.  The  command  message  and  response  message  (optional)  pair 
that  is  the  basis  for  communication  with  devices  on  a single  DIU  is  termed 
a transaction.  The  unique  operation  code  sent  in  the  command  message 
causes  a sequence  of  simple  DIU  operations  that  reads  sensors  or  actuator 
status  registers  or  writes  to  actuator  command  registers.  Additionally, 
the  DIU  formats  any  resulting  sensor  data  into  a response  message  and 
transmits  it  as  needed.  The  DIU  requires  some  overhead  processing  time  to 
decode  and  verify  the  message  and  prepare  the  response  message.  The  times 
assumed  for  all  operations  in  the  timing  estimate  are  illustrated  in  figure 
4. 1.3-1. 


The  second  major  I/O  activity  element  is  the  duration  of  the  command  and 
response  messages  sent  on  the  I/O  network.  The  transmission  rate  on  the 
I/O  network  is  2 megabits  per  second.  A primitive  format  assumed  for  these 
messages  is  illustrated  in  figure  4. 1.3-2.  The  input  I/O  activity  for  a 
rate  group  consists  of  a sequence  of  transactions  with  all  its  DIUs.  Each 
transaction  consists  of  a sensor  command  frame  followed  by  DIU  processing 
as  described  above  and  finally  a sensor  response  frame.  The  output  I/O 
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Figure  4. 1.3-2.  Primitive  DIU  Command  Response  Assumptions 


activity  consists  of  a sequence  of  output-only  transactions  for  all  the 
appropriate  DIUs.  These  output-only  transactions  contain  only  an  actuator 
command  frame.  The  equations  describing  the  duration  of  input  and  output 
I/O  activity  are  detailed  in  figure  4. 1.3-3. 

Flight  Control  Major  Group 

The  sensor  and  actuator  data  transfer  requirements  for  the  flight  control 
group  are  illustrated  in  figure  4. 1.3-4  (DIU  names  are  shown  in  fig. 

3. 2. 1-1).  This  figure  lists  the  specific  number  of  words  required  by  each 
DIU  within  each  rate  group  for  the  application  functions  allocated  to  the 
flight  control  group.  Evaluation  of  I/O  activity  duration  data  yields  the 
results  summarized  in  figure  4. 1.3-5.  The  computing  duration  is  based  on 
execution  of  the  allocated  control  subfunctions  on  a 3 mips  processor.  The 
mean  computing  workload  for  each  control  function  (less  the  allowance  for 
growth)  was  taken  from  section  4 of  reference  A.  A timeline  for  the 
application  activity  during  a major  frame  is  illustrated  in  figure  4. 1.3-6. 

Figure  4. 1.3-6  shows  an  overlap  in  the  application  computing  between  the 
100  Hz  rate  and  the  25  Hz  rate.  This  indicates  that  the  rate  groups  will 
contend  for  the  computing  processor  in  this  organization.  The  major 
characteristics  of  time  delay  for  this  organization  can  also  be  seen  in  the 
figure.  The  values  are  clearly  a fraction  of  a single  minor  frame,  thus 
well  below  the  update  rate  period  criterion. 

Engine  Control  Group 

The  sensor  and  actuator  data  transfer  requirements  for  each  engine  control 
group  are  illustrated  in  figure  4. 1.3-7.  The  resulting  input  and  output 
I/O  activity  duration  along  with  the  computing  duration  are  shown  in  figure 
4. 1.3-8.  A timeline  for  the  application  activity  by  rate  during  a major 
frame  is  illustrated  in  figure  4. 1.3-9. 

It  is  clear  that  the  engine  control  group  is  very  lightly  loaded  by  the 
application  when  compared  to  the  flight  control  group.  No  timing  problems 
are  apparent  at  this  stage  of  the  performance  development. 
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(Eqn  1)  input  * time  to  transmit  sensor  command  frames  + time  to  execute  sensor  command  frames  + 
time  to  transmit  sensor  response  frames 

(Eqn  2)  output-  time  to  transmit  actuator  command  frames  + time  to  execute  actuator  command  frames 
Time  to  transmit  sensor  command  frames: 

- # input  command  frames  X time  to  transmit  word  X words/input  command  frame 
Time  to  execute  sensor  command  frames: 

- # input  command  frames  X DIU  overhead  + total  # of  sensor  reads  X sensor  read  time  + 
total  # of  actuator  status  reads  X actuator  status  read  time  + total  # actuator  position  reads 
X actuator  position  read  time 

Time  to  transmit  sensor  response  frames: 

- total  # words  in  ail  sensor  response  frames  X time  to  transmit  word 
Time  to  transmit  actuator  command  frames: 

- ((#  actuator  command  frames  X overhead  words/actuator  command  frame)  + total  # of 
actuator  commands  + total  # of  actuator  safe  commands)  X time  to  transmit  word 

Time  to  execute  actuator  command  frames: 

- # actuator  command  frames  X DIU  + (total  # of  actuator  commands  X actuator  command 
time  + total  # of  actuator  safe  commands  X actuator  safe  command  time 


Figure  4. 1.3-3.  Input-Output  Activity  Execution 
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Figure  4.1 .3-4.  Flight  Control  Computer  Estimated  Application  Timing 
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Figure  4.1. 3-5.  Flight  Control  Computer  Estimated  Application  Timing  - Rate  Values 
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Figure  4. 1.3-7.  Engine  Control  Computer  Estimate  Application  Timing 
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Resulting  utilization: 

Application  computing  5.28% 

Application  I/O  6.17% 

Figure  4. 1.3-8.  Engine  Control  Computer  Estimated  Application  Timing  - Rate  Values 
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4.1.4  Initial  AIPS  Tiaing 


The  next  phase  in  the  performance  model  development  adds  more  detail  to  the 
modeling  of  the  I/O  activity.  The  elements  of  the  AlPS-based  candidate 
configuration  are  shown  in  figure  4. 1.4-1.  One  aspect  of  AIPS  operation  is 
the  exact  voting  of  output  data  and  the  source-congruent  voted  exchange  of 
input  data  across  FTP  channels.  The  model  of  I/O  activity  duration 
presented  in  the  previous  section  is  expanded  to  include  this  voting 
process,  in  which  the  IOP  uses  the  data  exchange. 

The  IOP  executes  some  preprocessing  and  postprocessing  functions  for  the 
I/O  activity.  The  IOP  prepares  each  command  frame  for  execution  by  loading 
the  input/output  sequencer  (IOS).  Similarly,  the  IOP  completes  processing 
of  sensor  response  frames  (input  data)  by  unloading  the  IOS.  Before 
sending  actuator  command  frames,  the  IOP  votes  all  of  the  associated  data 
while  loading  the  IOS.  Similarly,  after  all  sensor  response  frames  are 
received  the  data  are  distributed  to  all  FTP  channels  via  the  data 
exchange.  Since  the  sensor  command  frames  for  the  input  activity  do  not 
change  from  cycle  to  cycle,  it  is  assumed  that  the  IOP  does  not  vote  the 
associated  data.  Once  loading  is  complete,  the  IOS  sends  command  frames  to 
the  DIU  and  receives  any  response  frames,  executing  without  IOP  involvement 
until  all  the  transactions  in  the  chain  are  completed.  The  IOS  is  assumed 
to  require  10  microseconds  for  overhead  processing  between  consecutive 
network  transactions.  This  is  called  transaction  turnaround  time. 

In  this  phase,  each  rate  group  is  now  assumed  to  have  its  own  CP  and  IOP. 
The  rate  group  computing  is  explicitly  allocated  to  the  CP.  The  assumed 
sequencing  and  control  function  must  now  arbitrate  between  the  rate  groups 
for  the  use  of  the  single  network.  The  extra  system  loading  due  to  the 
output  voting  and  input  distribution  causes  some  additional  delay  in  the 
completion  of  lower  priority  output  I/O  activity  due  to  more  urgent  high 
priority  input  I/O  activity. 

The  speed  of  the  data  exchange  used  to  calculate  the  duration  of  IOP 
involvement  in  the  I/O  activity  was  6 microseconds  per  word  for  loading  the 
IOS  and  8 microseconds  per  word  for  unloading  the  IOS.  There  were  two 
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further  changes  to  the  modeling  of  the  I/O  activity  in  this  initial  AIPS 
timing  phase.  First,  the  actual  AIPS  network  protocol  is  used  for  data 
transfer  over  the  network  (fig.  4. 1.4-2).  This  figure  also  indicates  the 
amount  of  data  that  must  pass  through  the  data  exchange  for  each  actuator 
command  frame  and  sensor  response  frame.  Second,  the  DIU  fixed  overhead 
time  was  increased  to  20  microseconds.  The  overall  I/O  activity  time 
equations  for  the  initial  AIPS  timing  estimate  are  illustrated  as  equation 
3 and  equation  4 in  figure  4. 1.4-3. 

Flight  Control  Group 

The  phasing  of  activity  in  the  flight  control  group  was  altered  slightly  by 
changing  the  initial  scheduling  of  the  25  Hz  rate  group.  Rather  than  start 
all  three  rate  groups  in  the  very  first  minor  frame,  the  activity  for  the 
25  Hz  is  offset  by  starting  it  in  the  second  minor  frame.  The  sensor  and 
actuator  data  requirements  for  the  flight  control  group  are  updated  to 
reflect  the  data  exchange  usage  and  the  more  extensive  high  level  data  link 
control  (HDLC)  frame  formats,  as  illustrated  in  figure  4. 1.4-4.  The 
resulting  timing  data  are  summarized  in  figure  4. 1.4-5.  A timeline  of  this 
information  is  illustrated  in  figure  4. 1.4-6. 

Two  problems  are  observed  in  figure  4. 1.4-6.  First,  there  is  an  overlap  in 
the  second  and  fourth  minor  frame  between  the  100  Hz  input  activity  and  the 
50  Hz  output  activity  in  the  I0P.  Second,  there  is  overlap  between  the 
100  Hz  application  processing  and  25  Hz  application  processing  in  the  CP. 
This  indicates  that  contention  for  the  processor  will  occur  with  this 
initial  AIPS  organization.  Time  delay  is  still  well  within  the  one  update 
period  criteria. 

Engine  Control  Group 

The  sensor  and  actuator  data  requirements  for  each  engine  control  group  are 
updated  and  shown  in  figure  4. 1.4-7.  A summary  of  the  resulting  1/0 
activity  duration  data  is  presented  in  figure  4. 1.4-8.  A new  timeline  is 
illustrated  in  figure  4. 1.4-9.  There  are  no  apparent  timing  problems. 
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Figure  4. 1.4-2.  HDLC  Protocol  - DIU  Command/Response  Frame 


(Eqn  3)  input  - time  to  transmit  sensor  command  frames  + time  to  execute  sensor  command  frames  + 
time  to  transmit  sensor  response  frames  +time  to  unload  sensor  response 


(Eqn  4)  output-  time  to  load  actuator  commands  + time  to  transmit  actuator  command  frames  + time  to 
execute  actuator  command  frames 

Time  to  transmit  sensor  command  frames: 

« # input  command  frames  X time  to  transmit  word  X words/input  command  frame 

Time  to  execute  sensor  command  frames: 

- # input  command  frames  X DIU  overhead  + total  # of  sensor  reads  X sensor  read  time  + 
total  # of  actuator  status  reads  X actuator  status  read  time  + total  # actuator  position  reads 
X actuator  position  read  time 

Time  to  transmit  sensor  response  frames: 

« total  # words  in  all  sensor  response  frames  X time  to  transmit  word 

Time  to  unload  response: 

- total  # of  response  words  in  all  sensor  response  frames  X data  exchange  unload  rate 

Time  to  load  actuator  commands: 

- total  # of  actuator  commands  to  load  X data  exchange  load  rate 

Time  to  transmit  actuator  command  frame: 

» (#  actuator  command  frames  X overhead  words/actuator  command  frame)  + (total  # of 
actuator  commands  + total  # of  actuator  safe  commands)  X time  to  transmit  word 

Time  to  execute  actuator  command  frame: 

••  # actuator  command  frames  X DIU  + (total  # of  actuator  commands  X actuator  command 
time  + total  # of  actuator  safe  commands  X actuator  safe  command  time 

Figure  4. 1.4-3.  Input-Output  Activity  Timing  for  Initial  AIPS  Timing 
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SR  - Sensor  read 
AC  - Actuator  command 
ASC  - Actuator  safe  command 
AS  - Actuator  status 
AP  - Actuator  position 

Figure  4. 1.4-4.  Flight  Control  Computer  Initial  AIPS  Application  Timing 
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Resulting  utilization: 


CP  50.06% 

|OP  25.84% 

Network  32.28% 

Figure  4. 1.4-5.  Flight  Control  Computer  Initial  AIPS  Application  Timing  - Rate  Values 
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Figure  4. 1.4-6.  Flight  Control  Computer  Initial  AIPS  Application  Timing 
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Figure  4. 1.4-7.  Engine  Control  Computer  Initial  AIPS  Application  Timing 
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Rate 

Network 
input  (jis) 

DXof 
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Resulting  utilization: 


CP  5.28% 

IOP  3.34% 

Network  7.71% 

Figure  4. 1.4-8.  Engine  Control  Computer  Initial  AIPS  Application  Timing  - Rate  Values 
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4.1.5  Revised  AIPS  Timing 


In  the  revised  AIPS  timing  phase  of  the  performance  model  development  the 
overall  I/O  activity  is  reorganized  by  grouping  the  sensor  read  input  I/O 
activity  and  actuator  command  output  I/O  activity  into  a single  network, 
activity  per  rate  group.  This  I/O  organization  is  referred  to  as  grouped 
I/O.  In  this  strategy,  all  sensor  read  operations  and  actuator  write 
operations  within  a single  DIU  are  combined  into  one  transaction  per  rate 
group.  The  transmission  of  the  actuator  commands  from  the  previous  control 
cycle  is  combined  with  the  transmission  of  the  sensor  read  commands  for  the 
current  control  cycle.  This  reduces  the  loading  on  the  I/O  network  because 
DIUs  that  have  both  sensors  and  actuators  are  now  only  accessed  once  per 
application  cycle.  As  a consequence,  control  law  time  delay  will  increase. 
The  equation  used  to  calculate  the  duration  of  the  I/O  activity  is  shown  in 
figure  4. 1.5-1.  The  sequencing  and  control  function  now  only  keeps  track 
of  one  I/O  activity  per  rate  group.  A control  cycle  begins  with  the 
grouped  I/O  activity  that  transmits  the  commands  from  the  previous  cycle 
and  requests  sensor  data  for  the  current  cycle.  Since  the  I/O  activity 
starts  with  loading  actuator  commands,  the  IOP  activity  is  usually  the 
first  action  in  a control  cycle. 

The  final  change  to  the  model  is  the  assumption  of  a single  CP  and  IOP  that 
must  be  shared  by  the  different  rate  groups.  It  is  assumed  that  the 
control  function  allocates  the  CP  or  the  IOP  to  the  fastest  rate  group 
needing  service. 

Plight  Control  Group 

The  sensor  and  actuator  data  requirements  for  the  flight  control  group, 
reflecting  the  new  I/O  organization,  are  illustrated  in  figure  4. 1.5-2. 
Note  that  the  data  that  previously  appeared  in  the  actuator  command  frame 
now  appears  in  the  sensor  command  frame  column.  Also  the  total  number  of 
frames  is  reduced  by  the  number  of  actuator  command  frames.  The  revised 
I/O  activity  duration  data  are  summarized  in  figure  4. 1.5-3.  A timeline  is 
presented  in  figure  4. 1.5-4  for  the  flight  control  group.  The  effect  of 
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(Eqn  5)  network  activity  - time  to  toad  actuator  commands  + time  to  transmit  grouped  sensor/ 

actuator  commands  + time  to  execute  grouped  sensor/actuator  command 
frames  + time  to  transmit  response  frames  + time  to  unload  sensor  responses 

Time  to  load  actuator  commands: 

m total  # of  actuator  commands  to  toad  X data  exchange  toad  rate 

Time  to  transmit  grouped  sensor/actuator  commands: 

» ((#  command  frames  X words/command  frame)  + total  # actuator  commands  + total  number 

actuator  safe  commands)  X time  to  transmit  word 

Time  to  execute  grouped  sensor/actuator  command  frame: 

- # command  frames  X DIU  overhead  + Total  # sensor  reads  X sensor  read  time  + total  # 

actuator  command  X actuator  command  time  + total  # actuator  safe  commands  X actuator 
safe  command  time  + Total  # actuator  status  reads  X actuator  status  time  + total  # actuator 
positions  X actuator  position  time 

Time  to  transmit  response  frames: 

m ((total  # command  frames  X words/response  frame)  + total  # actuator  positions  + total  # 
actuator  status  + total  # sensor)  X time  to  transmit  word  + total  # command  frames  X 
transaction  turnaround  time 

Time  to  unload  response: 

- total  # of  response  words  to  data  exchange  X data  exchange  unload  rate 


Figure  4. 1.5 - 1.  Input-Output  Activity  Execution 
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Figure  4. 1.5-2.  Flight  Control  Computer  Revised  AIPS  Application  Timing 
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CP  50.06% 

I/O  25.34% 

Network  27.23% 

Figure  4. 1.5-3.  Flight  Control  Computer  Revised  AIPS  Application  Timing  - Rate  Values 
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the  change  to  grouped  I/O  is  to  reduce  somewhat  the  network  use  and  to 
increase  the  system  time  delay.  As  a result  of  the  change,  the  time  delay 
is  now  approximately  one  update  period. 

The  performance  data  developed  will  be  used  to  form  the  basis  for  the 
simulation  model.  Other  details  of  the  application  timing  requirements 
must  now  be  considered.  The  basic  detail  of  the  application  workload  has 
been  determined,  but  certain  key  interactions  due  to  resource  contention, 
fault  processing,  etc.,  require  more  sophisticated  analysis  methods.  At 
this  point  in  the  development  we  are  ready  to  build  a simulation  model. 
But  first,  based  on  the  initial  assessment  of  the  architecture 
configuration,  we  must  address  critical  areas  for  validation  and  what 
experiments  will  be  run  with  the  simulation. 

A. 2 Critical  Validation  Issues 

This  section  describes  some  high-level  critical  performance-related 
validation  issues  for  the  candidate  architecture.  These  critical  issues 
involve  ways  in  which  timing  performance  can  prevent  safe  operation. 
Special  situations  or  operating  circumstances  can  be  a key  factor.  These 
critical  validation  issues  are  identified  to  drive  the  development  of  the 
simulation  model  so  that  they  can  then  be  studied  early  in  the  design  cycle 
when  the  cost  benefit  impact  of  improvements  is  very  favorable. 

Two  performance-related  issues  are  to  be  studied  in  this  effort.  The  first 
is  the  effect  on  performance  of  the  relative  phasing  of  the  application 
activity  and  the  system  failure  detection,  identification  and 
reconfiguration  (FDIR)  activity.  The  second  is  the  effect  on  the 
application  activity  of  the  I/O  network  repair  actions. 

4.2.1  Application/FDIR  Coordination 

The  execution  of  the  application  cycle  (computing  processes  in  the  CP  and 
I/O  activity  processing  in  the  IOP)  will  be  affected  by  the  execution  of 
the  system  FDIR  processes.  FDIR  protects  the  computing  integrity  of  the 
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FTP  channel.  Certain  FTP  failures  are  catastrophic  if  not  handled  within  a 
fev  application  cycles.  FDIR  executes  at  the  rate  of  the  fastest 
application  cycle  to  guarantee  rapid  fault  reaction.  Each  FTP  channel  has 
a vatchdog  timer  for  failure  protection;  FDIR  must  reset  this  timer  within 
narrow  tolerances.  In  temporary  application  overload  situations,  then, 
FDIR  has  the  most  stringent  timing  requirement  and  must  therefore  have 
priority  over  the  application  processing.  The  concern  to  be  analyzed  is 
whether  certain  phasings  between  scheduled  application  execution  and  the 
FDIR  process  can  degrade  performance  unacceptably.  If  performance  can  be 
significantly  affected,  a mechanism  to  control  the  relative  phasing  will  be 
required. 


4.2.2  I/O  Network  Repair 

Each  major  group  in  the  reference  configuration  has  two  reconfigurable  I/O 
networks.  The  sensors  and  actuators  are  distributed  between  these  networks 
for  fault- tolerant  operation.  When  a failure  brings  down  one  network,  the 
application  continues  using  the  sensors  and  actuators  accessible  via  the 
other  network.  The  major  concern  is  the  interactions  between  the  repair 
activity  and  the  application  activity. 

Application  I/O  activity  is  terminated  on  the  faulty  network  for  the 
duration  of  the  repair  activity.  The  system  is  therefore  vulnerable  if  a 
fault  occurs  on  the  second  network  before  the  first  network  is  repaired. 
The  likelihood  of  this  catastrophic  event  is  dependent  on  the  duration  of 
the  network  repair.  Thus  the  network  repair  duration  is  a critical  issue. 

The  repair  activity  interacts  with  the  nominal  execution  of  the  application 
functions.  The  repair  algorithms  involve  many  processing  and  I/O  activity 
steps  using  the  IOP  and  the  network.  Timely  execution  of  repair  is 
affected  by  the  application's  need  to  communicate  over  the  unfaulted 
network,  which  also  involves  IOP  processing.  The  timing  performance  of  the 
application  must  be  acceptable  during  the  repair  activity.  Because  of  the 
complexity  of  the  interaction  of  the  repair  activity  and  the  application, 
the  duration  and  effect  of  the  repair  activity  is  addressed  most 
effectively  with  simulation  techniques. 
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Two  I/O  network  repair  strategies  are  evaluated:  one-shot  and  full  regrow. 
The  one-shot  strategy  is  characterized  by  rapid  diagnosis  and  specific 
repair  actions.  Full  regrow  is  the  same  process  used  to  grow  the  I/O 
network  at  power  on.  It  uses  a robust  sequence  of  steps  to  grow  a path  to 
all  good  devices  reachable  with  the  unfailed  network  elements. 

In  the  one-shot  repair  strategy,  when  a communication  fault  occurs,  a chain 
that  accesses  all  the  nodes  on  the  failed  network  is  executed.  Based  on 
the  nodes  that  did  not  respond,  the  network  manager  assumes  that  an  I/O 
link  has  failed  and  attempts  to  repair  the  failed  link  by  enabling  a spare 
link  that  is  connected  to  the  lost  nodes.  If  communication  has  been 
restored  to  all  the  lost  nodes,  the  link  failure  assumption  was  correct  and 
the  network  is  returned  to  service.  However,  if  some  of  the  lost  nodes 
remain  unreachable,  the  link  failure  assumption  was  wrong  and  a process 
associated  with  a node  failure  hypothesis  is  invoked.  If  at  any  point  in 
the  one-shot  process  it  becomes  clear  that  progress  is  impossible,  for  any 
reason,  a robust  regrow  algorithm  is  begun.  It  should  be  noted  that  the 
repair  algorithm  implemented  in  the  model  for  the  current  experiments  does 
not  support  the  repair  of  a node  failure  or  the  reversion  to  a regrow 

strategy. 

The  full  regrow  repair  strategy  makes  no  attempt  to  determine  the  type  of 
failure;  it  uses  a robust  algorithm  to  establish  a new  I/O  network  topology 
as  if  the  power  had  just  been  applied.  Unlike  the  one-shot  repair 
strategy,  the  regrow  algorithm  can  establish  a path  to  all  reachable  nodes 
(and  therefore  DIUs)  regardless  of  the  type  of  failure. 

4.3  Define  Experiments 

This  section  describes  the  experiments  to  be  performed  with  the  IAPSA  II 
simulation  model.  It  should  be  noted  that  experiment  1 was  conducted 
earlier  in  the  program  to  develop  a common  experimentation  interface. 
Therefore  the  experiment  numbering  for  the  preliminary  simulation 
experiments  begins  with  experiment  2. 
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4.3.1  Experiment  Configurations 


The  reference  configuration  comprises  three  major  groups:  a flight  control 
group  and  an  engine  control  group  for  each  engine.  The  composition  of 
these  groups  is  described  in  section  3.  The  experimental  concept  is  to 
perform  experiments  on  two  separate  models:  a model  of  the  flight  control 
group  and  a model  of  the  engine  control  group.  This  allows  comparison 
between  a large,  heavily  loaded  system  and  a relatively  small,  lightly 
loaded  system. 

4.3.2  Experiment  Procedure 

The  variability  of  the  processing  needs  of  the  application  and  the  system 
services  was  captured  by  modeling  elements  as  stochastic  processes.  To 
address  the  statistical  characteristics  of  the  reference  configuration, 
multiple  samples  of  the  experiment  variables  were  collected.  The 
experiment  data  were  then  plotted  on  histograms  to  assess  the  statistical 
aspects  of  the  system  behavior.  Data  from  100  major  frames  were  used  to 
evaluate  the  general  characteristics  of  the  application's  behavior. 

The  I/O  network  repair  runs  were  intended  to  determine  how  the 
application's  behavior  changes  during  the  repair  of  a fault.  Fifty  runs  of 
each  failure  case  were  conducted  to  randomly  cover  the  time  of  fault 
occurrence . 

4.3.3  I/O  Network  Repair  Time  (Experiment  2) 

The  objective  of  experiment  2 was  to  measure  the  time  needed  to 
successfully  return  a network  to  service  after  it  experiences  a network 
fault.  This  experiment  also  evaluated  the  effect  of  the  additional  network 
repair  processing  on  the  timing  performance  of  the  application.  This 
experiment  evaluated  both  configurations,  flight  control  and  engine 
control.  Each  active  link  in  the  network  was  failed  passively  in  this 
experiment.  The  link  is  failed  at  a random  time  during  the  second  major 
frame  and  the  experiment  run  terminated  one  major  frame  after  rhe 
completion  of  the  I/O  repair  activity. 
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The  experiments  were  run  with  both  the  rapid  one-shot  repair  strategy  and  a 
full  regrow  repair  strategy.  This  scoped  the  minimum  and  maximum  possible 
repair  times  for  single  faults.  Each  link  failure  case  was  repeated  50 
times  with  the  fault  occurring  at  a random  time  with  respect  to  the  major 
frame.  This  allowed  a coarse  assessment  of  the  relationship  between  fault 
occurrence  time  and  network  repair  time. 

4.3.4  I/O  Scheduling  (Experiment  3) 

The  purpose  of  experiment  3 was  to  evaluate  the  effect  of  the  I/O 
scheduling  mechanism  on  the  performance  of  the  application  during  normal 
operation.  The  system  services  software  has  two  mechanisms  available  to 
the  application  designer  to  schedule  the  application  I/O  activity, 
scheduled  I/O  and  on-demand  I/O.  In  on-demand  I/O,  at  the  beginning  of 
each  cycle,  the  application  executing  in  the  CP  makes  an  I/O  request  and 
then  suspends  itself.  When  the  I/O  has  completed,  the  application  process 
resumes.  In  scheduled  I/O,  the  system  software  executing  in  the  I0P  makes 
the  I/O  request  periodically.  The  application  computing  in  the  CP  is 
scheduled  every  cycle  by  the  completion  of  the  I/O  activity. 

Two  I/O  activity  organization  schemes  were  also  considered:  separated  I/O 
and  grouped  I/O,  which  were  briefly  discussed  in  section  4.1.  In  separated 
I/O,  the  I/O  activity  for  the  rate  group  is  separated  into  two  parts,  the 
input  I/O  activity  and  the  output  I/O  activity.  In  the  grouped  I/O  scheme, 
all  of  the  I/O  activity  is  grouped  together  and  performed  at  the  same  time. 

This  experiment  evaluated  the  effect  of  these  options  on  the  application 
performance.  There  is  a single  experiment  run  for  each  of  the  I/O 
scheduling  mechanism  and  I/O  activity  organization  combinations.  The 
duration  of  each  run  was  102  major  application  frames. 

4.3.5  FDIR/ Application  Phasing  (Experiment  4) 

The  objective  of  experiment  4 was  to  evaluate  the  effect  of  the  relative 
phasing  of  the  application  activity  and  the  system  FDIR  process.  The  FDIR 
and  application  demands  were  evaluated  during  normal  operation.  The  system 
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time  scheduler  assumed  for  this  study  has  a granularity  of  one  millisecond. 
That  is,  time-scheduled  tasks  can  only  be  specified  to  the  nearest  even 
millisecond.  The  10  specific  relative  phasing  situations  possible  because 
of  the  10  millisecond  minor  frame  period  were  analyzed.  In  each  simulation 
it  is  assumed  that  the  independent  FDIR  processes  in  the  CP  and  the  I0P  are 
scheduled  to  run  at  the  same  time.  The  experiment  was  defined  for  both  the 
flight  control  and  engine  control  configurations,  for  both  I/O  scheduling 
mechanisms,  and  for  both  I/O  activity  organizations. 

4.3.6  CP,  IOP,  I/O  System,  I/O  Network  Utilization  (Experiment  5) 

The  purpose  of  experiment  5 was  to  estimate  the  use  of  the  key  candidate 
system  resources  during  normal  operation.  Major  areas  of  resource 
contention  vere  modeled  for  this  experiment.  This  includes  contention 
between  the  different  application  rate  groups,  as  well  as  the  previously 
described  contention  between  the  application  rate  groups  and  the  time- 
critical  FDIR  function.  A preemptive  priority  sequencing  and  control 
algorithm  is  modeled  to  control  processor  allocation.  Accounting  for 
contention  produced  a more  realistic  growth  capability  estimate  and  allowed 
an  evaluation  of  the  effect  of  execution  variability.  Measurements 
representative  of  each  of  the  application  performance  requirements  defined 
in  section  4.1  are  made  for  normal  operation  and  the  network  failure  cases. 
The  application  performance  data  for  failure  cases  are  only  collected 
during  the  fault  recovery  action.  Thus  comparison  of  failed  and  non-failed 
cases  will  show  how  the  operation  changes  during  the  fault  recovery 
process. 


4.3.7  Experiment  Execution  Strategy 

The  experiment  configurations  for  data  collection  are  illustrated  in  table 
4. 3. 7-1.  The  experiments  vere  performed  in  the  following  order:  (1)  FDIR/ 
application  phasing  (experiment  4);  (2)  I/O  scheduling  mechanism 
(experiment  3);  and  (3)  I/O  link  repair  (experiment  2).  The  CP,  IOP,  I/O 
system,  I/O  network  utilization  experiment  5 data  vere  collected  during  the 
running  of  the  previous  experiments.  Table  4. 3. 7-2  defines  the  number  of 
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Table  4.3. 7-1.  Experiment  Configuration 


Experiment 

No. 

Configuration  ID 

Layout 

FDIR  Coordination 

I/O  Scheduling 

I/O  Grouping 

1 

Flight  control 

Yes 

On  demand 

Grouped 

3 

2 

Flight  control 

Yes 

On  demand 

Separated 

3 

Flight  control 

Yes 

Scheduled 

Grouped 

4 

Flight  control 

No 

On  demand 

Grouped 

4 

5 

Flight  control 

No 

On  demand 

Separated 

6 

Flight  control 

No 

Scheduled 

Grouped 

7 

Engine  control 

Yes 

On  demand 

Grouped 

3 

8 

Engine  control 

Yes 

On  demand 

Separated 

9 

Engine  control 

Yes 

Scheduled 

Grouped 

10 

Flight  control  regrow 
repair  strategy 

Yes 

Scheduled 

Grouped 

2 

11 

Flight  control  one-shot 
repair  strategy 

Yes 

Scheduled 

Grouped 

12 

Engine  control  regrow 
repair  strategy 

Yes 

On  demand 

Grouped 

13 

Engine  control  one-shot 
repair  strategy 

Yes 

On  demand 

Grouped 

i 

Engine  control 

No 

On  demand 

Grouped 

4 

Engine  control 

No 

On  demand 

Separated 

■H 

Engine  control 

No 

Scheduled 

Grouped 
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Table  4. 3. 7-2.  Configuration  for  Experiment  Execution 


Experiment  ID 

Configuration  ID 

No.  of  phase 
or  faults 

Range  of  run  IDs 

Total  run  potential 

4 

6 

10 

1 

10 

14 

10 

1 

10 

15 

10 

1 

10 

16 

10 

1 

10 

2 

10 

18 

1..50 

900 

11 

18 

1..50 

900 

12 

4 

1..50 

200 

13 

4 

1..50 

200 

of  possible  faults  or  relative  FDIR  phasings  considered  for  each  experiment 
configuration,  as  well  as  the  number  of  repetitions  for  each  link  fault 

experiment . 


An  actual  application's  demands  will  not  necessarily  grow  uniformly  across 
all  the  system  resources.  Therefore,  to  assess  growth  capability 
utilization  was  measured  for  four  key  resources:  the  CP,  IOP,  I/O  system, 
and  I/O  network.  The  CP  utilization  measures  its  use  in  computing  the 
application  control  laws  and  the  system  FDIR.  The  IOP  utilization  measures 
its  use  in  the  loading  and  unloading  of  application  I/O  activity,  network 
manager  processing  and  system  FDIR.  The  I/O  system  utilization  measures 
the  end  to  end  operation  of  the  I/O  networks  for  application  activity.  The 
I/O  system  utilization  starts  when  an  application  I/O  request  is  made  and 
ends  when  all  application  activity  is  complete  and  the  system  can 
immediately  respond  to  a new  request.  This  utilization  figure  is  intended 
to  measure  the  ability  of  the  I/O  system  to  handle  additional  I/O  requests. 
The  I/O  network  utilization  measures  the  time  from  the  beginning  to  the  end 
of  IOS  execution  of  I/O  activity. 


Deadline  margin  is  a figure  of  merit  that  indicates  how  well  the  system  is 
meeting  its  periodic  control  cycle  requirements,  that  is,  how  close  the 
system  is  to  missing  a time-critical  action.  The  critical  actions  include 
updating  an  input  or  an  output  set  of  I/O  data  to  complete  the  processing 
for  one  control  cycle  before  the  scheduled  starting  time  for  the  next 

cycle. 

The  time  delay  figure  of  merit  is  an  overall  indicator  of  time  delay  for  a 
particular  rate  group.  The  value  is  computed  as  the  difference  between  the 
start  of  an  I/O  activity  in  one  cycle  and  the  conclusion  of  an  I/O  activity 
in  the  next  cycle.  Deadline  margin  and  time  delay  were  illustrated  in 

figure  4. 1.1-1. 


4.4  Build  Model 

This  section  describes  the  development  of  a simulation  that  models  the 
behavior  of  an  implementation  concept  for  the  reference  configuration. 
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4.4.1 


Performance  Tool 


Several  tools  were  evaluated  for  developing  the  IAPSA  II  performance  model. 
A major  shortcoming  of  most  tools  evaluated  was  their  inability  to 
represent  algorithms.  This  capability  is  necessary  since  it  allows  some 
key  timing  parameters  to  be  established  using  prototype  algorithms. 

Boeing  Advanced  Systems  selected  the  Discrete  Event  Network  (DENET) 
simulation  language  for  the  development  of  the  simulation  model  for  the 
IAPSA  II  reference  configuration.  DENET  was  developed  at  the  University  of 
Wisconsin's  computer  science  department  by  Dr.  Miron  Livny.  It  is  a 
discrete  event  simulation  language  based  on  the  Discrete  Event  System 
Specification  modeling  methodology.  This  methodology  is  complemented  with 
the  MODULA  II  programming  language,  which  results  in  a simulation  language 
capable  of  developing  modular  system  simulations  at  any  level  of  detail. 
This  feature  allows  the  DENET  tool  to  represent  algorithms. 

DENET  simulations  are  composed  of  discrete  event  modules  (DEVM)  and  arcs, 
which  connect  outputs  of  one  DEVM  to  inputs  of  another.  Each  DEVM  is 
programmed  to  contain  some  function  of  the  system;  the  function  can  be 
either  a high-level  abstraction  or  a very  detailed  emulation.  DEVMs 
receive  input  and  generate  output  through  ports.  The  ports  of  DEVMs  are 
interconnected  with  arcs.  A simulation  model  consists  of  a group  of  DEVMS 
connected  together  with  arcs.  Each  instance  of  a DEVM  is  characterized 
with  input  parameters.  The  input  parameters  allow  the  module  to 
parameterize  the  specific  DEVM's  behavior  so  that  modular  building  blocks 
can  be  supported. 

Discrete  Event  Module 

A fundamental  feature  of  a DEVM  is  its  connections  with  other  DEVMs.  The 
connections  are  implemented  with  input  ports  and  output  ports.  A port  is 
created  on  a DEVM  when  a connection  is  made  to  another  DEVM  with  an  ARC. 
The  orientation  of  the  ARC  defines  whether  a port  is  an  input  port  or  an 
output  port.  DEVM  ports  are  associated  with  either  an  INPUT  event  or  an 
output  variable.  Each  INPUT  event  and  OUTPUT  variable  has  an  associated 
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data  type  for  transferring  information  when  the  variable  is  assigned.  The 
data  type  can  be  a simple  Boolean  or  an  integer,  or  can  be  a composite  type 
such  as  a record.  Output  from  a DEVM  is  generated  with  an  assignment 
statement  to  an  output  variable.  The  output  port  is  generally  connected  to 
an  input  port  on  another  DEVM.  At  the  time  an  output  is  assigned,  an  input 
event  is  triggered  in  the  destination  module.  The  input  event  is  the 
mechanism  by  which  the  modeler  controls  the  processing  in  the  DEVM.  The 
resulting  processing  can  change  the  state  of  the  DEVM  based  on  the  received 
data,  perform  a complex  algorithm,  and/or  schedule  an  output  port 
assignment  to  take  place  at  a defined  future  time. 

An  example  of  an  input  event  and  output  variable  for  a DEVM  that  models  an 
AIPS  node  (AIPSNODE)  is  shown  in  figure  4. 4. 1-1.  The  input  event  has  the 
name  NodeCommandFrame  and  the  output  variable  is  named  NodeResponseFrame. 
When  an  input  event  occurs,  the  AIPSNODE  processing  is  initiated.  An 
example  of  the  event-driven  processing  is  shown  in  the  following  AIPSNODE 
DEVM  description.  The  first  action  taken,  if  the  input  event  message 
corresponds  to  an  enabled  node  port,  is  to  assign  the  received  message  to 
the  output  variables  corresponding  to  all  other  enabled  node  ports.  The 
second  action  is  to  examine  the  message  to  see  if  it  contained  a command 
for  that  specific  node.  If  true,  the  directed  action  is  taken,  and  a 
response  message  is  generated  and  assigned  to  the  NodeResponseFrame  output 
variables  corresponding  to  the  node's  enabled  ports. 

ARC  Definition 


An  ARC  definition  is  used  to  connect  output  variables  of  a DEVM  to  the 
input  events  of  other  DEVMs , as  illustrated  in  figure  4.4. 1-2.  This  figure 
shows  half  of  the  connection  between  two  AIPSNODE  DEVMs  in  a network.  The 
ARC  definition,  NodeToNode,  defines  the  output  port  NodeResponseFrame  to  be 
connected  to  the  input  port  NodeCommandFrame. 

Parameter  Characterization 


The  parameters  of  a DEVM  are  used  to  fully  characterize  the  behavior  of  a 
DEVM.  One  use  is  the  definition  of  a specific  instance  of  a generic  DEVM 
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Figure  4.4. 1-1.  DEVM  I/O  Definition  forAIPS  Node 
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NodeToNode  = (NodeResponseFrame  NodeCommandFrame) 
Figure  4.4. 1-2.  ARC  Definition  for  Inter-AIPS  Node  Connections 
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such  as  the  definition  of  an  AIPSNODE  illustrated  by  figure  4.4. 1-3.  The 
generic  AIPSNODE  DEVM  has  five  parameters;  the  first  two  integer  values, 
NetvorkID  and  NodeNumber,  are  used  to  define  the  specific  I/O  network  node 
interconnections.  The  SequencerTimeUpper  and  SequencerTimeLower  parameters 
are  real  numbers  that  define  the  limits  of  the  uniform  distribution  that 
the  AIPSNODE  uses  to  determine  the  time  interval  between  the  reception  of  a 
valid  command  and  the  transmission  of  a response.  The  InitialConfiguration 
parameter  is  used  by  the  AIPSNODE  to  set  the  configuration  of  its  ports  at 
simulation  initialization  time. 

Simulation  Topology  File 

The  DENET  simulation  is  set  up  with  a topology  file  that  defines  DEVNs, 
their  parameter  values,  and  their  interconnections.  An  example  topology 
file  illustrating  each  of  these  features  is  shown  in  figure  4.4. 1-4.  The 
top  section  indicates  that  there  are  five  instances  of  AIPSNODE  in  this 
simulation  and  that  their  DEVM  numbers  are  70  through  74.  The  next  section 
shows  the  inter-DEVM  connections  with  the  NodeToNode  ARC  definition.  An 
input/output  port  combination  is  created  for  each  connection  made  with  an 
ARC  connection.  Finally,  the  configuration  parameters  of  each  AIPSNODE  are 
shown.  By  implementing  other  functions  in  DEVMs  and  defining  ARC 
definitions,  a complete  simulation  of  the  reference  configuration  was 
developed . 

4.4.2  Simulation  Model 


The  following  paragraphs  describe  the  functionality  of  the  DEVMs  used  in 
modeling  the  reference  configuration. 

Some  problems  were  encountered  during  the  development  of  the  models  for  the 
AIPS  elements  because  the  architecture  implementation  concept  was  still  in 
development.  As  the  model  development  progressed,  certain  assumptions  were 
made  about  how  functions  were  implemented  and  how  much  time  each  required. 
The  intent  in  these  cases  was  to  err  on  the  optimistic  side.  This  has 
resulted  in  simulation  models  that  are  AlPS-like  in  overall  behavior  hut 
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Figure  4.4. 1-3.  Parameter  Definitions  for  AIPS  Node 
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[70|71 ,72]:  * NodeToNode; 

[71 170,72,73]:  - NodeToNode; 

[72(70,71 .74]:  * NodeToNode;  Defines  internode  connections  shown  above 
[73|71,74]:  * NodeToNode; 

[74|72,73]: « NodeToNode; 


70:  *{2  1 0.000315  0.000385  { T T T T F }} 
71:  = {2  2 0.000315  0.000385  { T T T T F }} 
72:  = {2  3 0.00031 5 0.000385  { T T T T F }} 
73:  = {2  4 0.000315  0.000385  { T T T T F }} 
74:  = {2  5 0.00031 5 0.000385  { T T T T F }} 


Assigns  values  to  parameters  of  each  node 


Figure  4.4. 1-4.  Example  Topology  File 
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not  guaranteed  to  match  any  current  or  future  AIPS  implementation.  Before 
describing  the  specific  DEVMs,  the  steps  involved  in  accomplishing  an 
application  I/O  request  will  be  reviewed. 

Application  I/O  Activity 


Application  I/O  activity  involves  the  interaction  of  many  system  elements. 
The  process  resulting  from  a request  made  by  the  application  computing  is 
illustrated  in  figure  4. 4. 2-1.  The  figure  shows  the  significant  activity 
by  system  element.  The  IOP  responds  to  the  I/O  request  by  loading  the 
necessary  data  and  transferring  control  to  the  IOS.  The  IOS  sends  the 
individual  command  frames  to  the  DIUs  over  the  network  and  collects  the 
response  frames  from  the  DIUs.  When  the  IOS  is  finished,  the  IOP  collects 
the  DIU  responses  and  makes  them  available  to  the  CP  via  the  data  exchange. 
The  application  can  then  process  the  DIU  responses.  An  overview  of  the 
interaction  of  the  DEVMs  is  provided  by  the  following  description  of  how 
this  sequence  is  implemented  in  the  simulation  model. 

The  DEVMs  that  model  the  above  sequencing  are  illustrated  in  figure 
4. 4. 2-2.  One  application  rate  group  is  modeled  by  one  instance  of  the 
application  DEVM.  When  it  is  time  for  the  application  to  execute,  it  makes 
a request  to  the  processor  DEVM  representing  the  CP.  The  processor 
notifies  the  application  when  the  application's  processing  is  complete  for 
the  current  cycle.  The  application  may  then  make  an  I/O  request  to  the  I/O 
service  DEVM,  as  illustrated  in  figure  4. 4. 2-1. 

To  execute  the  I/O  request,  the  10  service  must  acquire  the  IOP  to  load  the 
data  needed  for  the  current  I/O  cycle.  The  10  service  then  makes  a 
processing  request  to  the  instance  of  the  processor  DEVM  that  models  the 
IOP  sequencing  and  control  function.  The  processor  notifies  the  10  service 
when  it  has  completed  the  10  service's  processing  request.  At  this  point 
the  10  service  commands  an  IOS  for  each  network  to  execute  the  I/O 
activity. 


The  IOS  DEVM  sends  messages  to  the  network  and  collects  the  responses.  All 
the  DEVMs  modeling  the  network  (nodes  and  DIUs)  receive  the  command  frames. 
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Figure  4.4.2- 1.  Application  Cycle 
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The  DEVM  addressed  in  the  command  frame  transmits  a response  to  the 
network..  When  the  I/O  activity  is  complete,  the  10  service  makes  another 
processing  request  to  the  processor  DEVM  to  unload  the  networks.  When  the 
10  service  is  notified  that  the  IOP  has  completed  its  request,  the  10 
service  notifies  the  application  DEVM  that  its  I/O  request  has  been 
completed. 

At  this  point  the  application  DEVM  has  sensor  data  to  process.  It  makes  a 
request  to  the  instance  of  the  processor  DEVM  modeling  the  CP  control 
function  for  the  appropriate  processing  time.  The  following  sections 
describe  these  DEVMs  in  detail. 

Processor 

Each  FTP  channel  is  composed  of  two  CPUs:  an  I/O  processor  (IOP)  and  a 
computational  processor  (CP).  All  CPs  and  all  IOPs  in  an  FTP  execute  in 
instruction  synchronization.  This  organization  is  depicted  in  figure 

4.4.2- 3(a).  For  the  defined  experiments,  it  can  be  assumed  that  the  CPs 
and  the  IOPs  remain  in  synchronization.  With  this  assumption,  a multiple- 
channel  FTP  can  be  modeled  as  a single-channel  FTP,  as  illustrated  in 
figure  4.4.2-3(b) . This  modeling  simplification  is  critically  dependent  on 
the  operation  of  multiple  I/O  networks  and  the  process  that  ensures  that  a 
multiple-channel  FTP  remains  in  synchronization. 

As  depicted  in  figure  4. 4. 2-2,  two  different  instances  of  the  processor 
DEVM  support  the  processing  requirements  of  the  I/O  system  and  the 
application.  The  key  processor  DEVM  characteristics  are  listed  in  figure 

4. 4. 2- 4.  The  processor  DEVM  models  the  sequencing  and  control  functions 
that  execute  on  either  the  CP  or  IOP.  This  sequencing  is  based  on  a 
preemptive  priority  model  in  which  the  highest  priority  process  ready  for 
execution  acquires  the  processor  and  retains  it  until  it  completes  or  until 
a higher  priority  process  becomes  ready.  The  processor  maintains  a 
priority  queue  of  processes  waiting  to  use  the  processor.  When  a process 
completes,  the  first  element  of  this  queue  acquires  the  processor.  If  a 
process  makes  a request  to  use  the  processor,  it  is  inserted  into  this 
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Figure  4.4.2-4.  Processor  DEVM 


priority  queue  if  its  priority  is  not  higher  than  the  process  currently 
running  on  the  processor.  If  its  priority  is  higher,  it  acquires  the 
processor  and  the  currently  running  process  is  inserted  into  the  queue. 

Each  application  process  is  assigned  a priority,  with  the  faster  rates 
having  higher  priority.  The  FDIR  process  is  assigned  a priority  higher 
than  the  application  processes  and  executes  at  the  rate  of  the  fastest 
application.  In  the  IOP,  the  processing  related  to  an  application  I/O 
activity  is  assumed  to  have  the  same  priority  as  the  application  computing. 
Again,  the  FDIR  is  assigned  a higher  priority  than  all  the  application 
priorities  and  executes  at  the  fastest  application  rate.  The  processes 
related  to  the  repair  of  the  I/O  network  are  assigned  a lower  priority  than 
all  the  application  priorities. 

Efficiency  is  a concern  for  all  system  services  functions.  Overhead 
processing  is  required  in  preemptive  priority  systems  to  handle  the 
different  processes.  This  overhead  can  dominate  a processor's  activity, 
depending  on  the  sequence  in  which  processes  become  ready  to  execute  and 
the  amount  of  time  needed  to  switch  processes.  A value  of  0.300 
millisecond  was  used  to  model  the  time  needed  for  sequencing  and  control 
overhead  in  the  processor  DEVM.  A process  switch  is  assumed  to  be  an 
uninterruptable  operation.  In  some  situations  a process  can  become  ready 
while  another  context  switch  is  in  progress.  In  this  case  the  processor 
performs  two  switches.  At  the  completion  of  the  first,  the  system 
recognizes  the  new  higher  priority  request  and  immediately  switches 
processes  again. 

10  Service 

The  10  service  DEVM  models  the  software  functions  that  execute  primarily  in 
the  IOP.  This  software  communicates  with  the  I0S  DEVM  and  the  application 
DEVM.  The  key  10  service  DEVM  characteristics  are  listed  in  figure 
4. 4. 2-5.  The  model  focuses  on  the  software  that  controls  the  sequencing  of 
pre-  and  post-processing  activity  in  response  to  an  1/0  request.  Some  10 
service  functions  reside  in  the  CP  for  interface  reasons.  These  were 
assumed  to  take  negligible  processing  time  in  the  model. 
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Figure  4A.2-5.  lOService  DEVM 


The  10  service  process  depicted  in  figure  4. 4. 2-6  controls  access  to  the 
I/O  networks.  This  model  was  developed  as  a result  of  initial  simulation 
efforts  and  differs  from  the  preliminary  AIPS  design.  There  are  4 steps  to 
the  execution  of  am  I/O  request:  load  command  frame  data,  start  IOS,  I/O 
completion  poll,  and  unload  the  response  frame  data.  The  IOSs  execute  the 
individual  transactions  of  the  I/O  activity  without  IOP  involvement.  Note 
that  the  10  service  was  modeled  as  separate  tasks,  one  dedicated  to  each 
application  rate  group  and  one  for  the  network  manager.  This  model  was 
created  when  a previous  version,  based  on  a preliminary  AIPS  concept,  could 
not  satisfy  the  flight  control  application  update  requirements.  The 
separate  task  model  allowed  some  preemptive  activity  on  the  IOP  without 
affecting  the  IOS  execution. 

A semaphore  was  employed  to  protect  the  execution  of  the  application  IOS 
activity.  The  I/O  network  is  protected  when  the  IOSs  are  commanded  to 
start  and  released  after  the  I/O  completion  poll.  The  modeled  approach 
minimizes  the  time  that  the  I/O  networks  are  in  a nonpreemptable  state  and 
relies  on  the  preemptive  priority  scheduler  to  resolve  the  contention 
between  I/O  requests  from  the  different  application  rates  and  the  network 
manager.  Assigning  high  priority  to  faster  application  rate  groups  allows 
the  application  activity  with  the  closest  deadline  to  be  serviced  first. 

In  the  10  service  model  the  IOP  is  free  for  lower  priority  processing  after 
it  starts  the  IOSs.  The  10  service  schedules  an  I/O  completion  poll  using 
the  underlying  system  time  schedule  function.  The  I/O  completion  poll 
checks  for  the  completion  of  the  network  activity  for  an  I/O  request  and 
begins  to  unload  the  collected  data.  Each  I/O  request  has  a defined 
completion  poll  interval  that  guarantees  that  the  activity  is  complete  when 
the  I/O  networks  are  operating  normally.  The  I/O  completion  poll  occurs  at 
integer  milliseconds  of  system  time.  This  is  due  to  the  assumed  underlying 
system  time  scheduling  granularity  of  one  millisecond. 

An  example  of  the  contention  between  application  rates  in  the  10  service  is 
shown  in  figure  4. 4. 2-7.  The  situation  is  that  the  50  Hz  rate  has  an  I/O 
request  that  has  progressed  to  its  execute  state.  At  this  point,  the 
100  Hz  rate  initiates  an  I/O  request.  Because  the  IOP  is  free,  it  can 
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Figure  4.4.2-B.  I O Service  Access  Contention 


process  the  100  Hz  I/O  request  until  it  is  time  to  start  the  IOSs.  The 
100  Hz  I/O  request  is  then  suspended,  because  the  50  Hz  I/O  process 
controls  the  semaphore.  When  the  50  Hz  I/O  completion  poll  occurs,  the 
50  Hz  I/O  process  releases  the  semaphore  making  100  Hz  I/O  process  ready. 
The  100  Hz  I/O  process  starts  the  IOS  with  the  100  Hz  activity,  schedules 
its  own  completion  poll,  and  relinquishes  the  IOP.  The  50  Hz  data  is  then 
unloaded  from  the  network  interfaces  because  it  is  the  highest  priority  job 
waiting  for  the  IOP. 

The  IOS  execution  of  network  manager  I/O  activity  can  take  place  at  the 
same  time  as  application  I/O  activity.  When  a communication  fault  occurs 
on  a network,  no  further  application  I/O  activity  takes  place  on  that 
network  until  the  I/O  network  manager  repairs  the  fault.  Thus,  during 
failure  recovery,  the  application  I/O  activity  will  be  restricted  to  one 
network  and  the  network  manager  activity  will  be  restricted  to  the  other 
network.  There  will  be  contention  between  the  application  and  the  network 
manager  for  the  IOP,  but  the  network  manager  I/O  activity  is  unconstrained 
on  the  network  being  repaired. 

Application 

The  application  is  a generic  DEVM  that  models  the  functionality  of  a single 
application  rate  group.  The  application  DEVM,  whose  key  characteristics 
are  listed  in  figure  4. 4. 2-8,  can  be  configured  to  perform  the  workload  of 
any  flight  control  or  engine  rate  group.  Its  execution  sequence  can  be 
configured  for  either  on  demand  or  scheduled  I/O.  The  DEVM  models  data- 
dependent  processing  requirements  using  a normal  workload  distribution  for 
the  needs  of  each  application  cycle. 

Input/Output  Sequencer 

The  IOS  DEVM  executes  chains  requested  by  the  10  service  DEVM  and  collects 
data  resulting  from  chain  execution.  It  provides  the  10  service  with  a 
status  variable  that  corresponds  to  the  state  of  IOS  execution.  This 
status  variable  indicates  whether  the  IOS  has  completed  the  chain  it  is 
executing.  The  1/0  service  also  has  the  ability  to  stop  the  IOS's 
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Figure  4.4.2-8.  Application  DEVM 


execution  of  a chain  at  anytime.  When  commanded  to  start  a chain,  the  IOS 
DEVM  sends  command  frames  to  the  adjacent  node  and  waits  for  the  response 

frames  as  needed  until  the  I/O  activity  is  finished.  Its  key 

characteristics  are  listed  in  figure  4. 4. 2-9. 

Node 

The  I/O  network  node  is  the  element  used  to  construct  the  mesh  configurable 
network.  During  normal  operation,  the  AIPSNODE  DEVM  node  acts  a 
rebroadcast  element.  Any  activity  received  on  an  enabled  port  is 
immediately  retransmitted  out  all  the  other  enabled  ports.  The  AIPSNODE 

responds  to  reconfiguration  commands  addressed  to  it  by  changing  its  port 

configuration  and  then  sending  a response  frame  that  contains  the  node  s 
status.  This  allows  detailed  modeling  of  the  network  repair  activity 
directed  by  the  network  manager  to  reconfigure  around  faults.  A null 
command  to  a node  results  in  the  node  transmitting  its  status.  AIPSNODE 
DEVMs  interface  with  other  AIPSNODE  DEVMS,  IOS  DEVMs,  or  DIU  DEVMS.  Their 
key  characteristics  are  listed  in  figure  4.4.2-10. 

DIU 

The  DIU  DEVM  models  the  network  device  to  which  the  application  sensors  and 
actuators  are  connected.  The  DIU  DEVM  models  the  receipt  of  messages  from 
the  application.  The  DIU  model  schedules  the  transmission  of  a response 
message  at  a time  that  reflects  the  DIU  processing  time  described  in 
section  4.1.  The  DIU  DEVM,  whose  key  characteristics  are  listed  in  figure 
4.4.2-11,  models  the  statistical  variation  of  the  duration  of  DIU 
processing  time. 

Network  Manager 


The  network  manager  is  responsible  for  maintaining  communications  between 
the  application  process  and  the  DIUs.  The  10  service  DEVM  notifies  the 
network  manager  DEVM  when  the  application  process  encounters  a 
communication  fault.  From  this  point  on,  the  10  service  does  not  execute 
any  application  chains  on  the  faulty  I/O  network  until  the  network  manager 
notifies  the  10  service  that  the  repair  is  complete. 
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Figure  4.4.2-9.  IOS  DEVM 
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Figure  4.4.2-10.  AIPS  Node  DEVM 


The  network  manager  DEVM  implements  two  different  types  of  strategies  for 
repairing  I/O  network  faults,  one-shot  and  regrow.  Prototype  algorithms 
for  both  of  these  strategies  are  implemented  in  the  DEVM,  whose  key 
characteristics  are  listed  in  figure  4.4.2-12.  A configuration  item  in  the 
10  service  DEVM  dictates  which  type  of  strategy  will  be  used  in  the  current 
experiment  to  repair  the  I/O  network.  This  allows  a common  DEVM  to  be  used 
for  both  sets  of  experiments. 

4.4.3  Development  Problems  with  Performance  Model 

The  10  service  DEVM  presented  extreme  difficulty  during  the  development  of 
the  simulation  model.  This  was  primarily  due  to  the  complex  functionality 
of  this  process.  Modeling  difficulty  early  in  the  development  is  probably 
a good  sign  of  impending  difficulty  in  the  implementation  phase.  The  10 
service  was  not  only  a complex  function  but  also  had  demanding  performance 
requirements.  Performance  problems  in  the  early  simulation  steps  led  to  the 
separate  task  structure  for  10  service  shown  in  figure  4. 4. 2-6.  As 
improbable  as  it  seems,  this  structure  was  actually  simpler  than  the 
original  design.  This  structure  still  has  some  remaining  adverse 
performance  characteristics.  This  is  a good  example  of  the  benefit  of 
performance  modeling  in  exposing  concept  difficulties  early  in  the  design 
cycle. 

4.4.4  Simulation  Input  Values 

The  values  used  by  Boeing  for  certain  simulation  timing  input  parameters 
are  shown  in  figures  4. 4. 4-1  through  4. 4. 4-3.  The  AIPS  parameters  that  do 
not  vary  with  simulation  configuration  are  illustrated  in  figure  4. 4. 4-1. 
Most  of  these  parameters  relate  to  time  needed  by  system  overhead  functions 
to  support  the  application  activity.  Parameters  unique  to  the  flight 
control  configurations  are  shown  in  figure  4. 4. 4-2.  Parameters  unique  to 
the  engine  control  configurations  are  shown  in  figure  4. 4. 4-3. 
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Figure  4.4.2- 12.  Network  Manager  DEVM 
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Figure  4.4.4-1.  AIPS  Time  Elements  (ns) 
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Figure  4.4.4-2.  Flight  Control  Time  Elements  (ns) 
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Figure  4.4.4-3.  Engine  Control  Time  Elements  (ns) 


4.5 


Evaluate 


This  section  presents  a high-level  discussion  of  the  results  obtained  from 
each  experiment  using  DENET.  The  steps  taken  to  analyze  the  simulation 
data  from  each  experiment  are  discussed  individually.  The  conclusions 
drawn  from  these  results  are  discussed  in  section  4.6. 

4.5.1  FDIR/ Application  Phasing  (Experiment  4) 

This  experiment  evaluates  the  effect  of  the  relative  phasing  of  the  high- 
priority  system  FDIR  process  and  the  application  activity.  For  each 
configuration  shown  in  table  4. 3. 7-1,  data  were  collected  from  execution  of 
100  major  frames. 

Flight  Control  Group 

For  two  of  the  configurations  (4  and  5),  the  application  was  unable  to  meet 
any  control  cycle  deadlines.  These  two  unsuccessful  configurations 
correspond  to  the  on-demand  I/O  scheduling  option  and  the  separated  I/O 
configuration  options  for  the  flight  control  group.  The  simulation  result 
showed  that  the  flight  control  group  was  overloaded  to  the  point  that  the 
application  could  not  perform  its  function  using  either  of  these 
organization  options.  Consequently,  configuration  4 and  configuration  5 
were  eliminated  as  possible  candidates. 

A summary  of  the  experimental  data  for  configuration  6 (scheduled  grouped 
I/O  organization)  is  presented  in  table  4.5. 1-1.  The  minimum  deadline 
margin  is  a strong  indicator  of  how  close  the  application  timing  demands 
are  to  being  violated.  (The  minimum  value  in  the  table  is  the  smallest 
value  observed  during  the  experiment  runs.)  The  50  Hz  rate  group  misses 
computing  deadlines  with  five  of  the  ten  possible  phasings  (phase  1,  2,  3, 
7,  and  8),  which  is  unacceptable.  Examination  of  the  data  reveals  that  the 
deadline  margin  distribution  is  very  close  to  zero  for  the  five 
unacceptable  phasings.  Furthermore,  the  data  indicated  that  these  cases 
correlated  with  frames  having  somewhat  larger  than  average  50  Hz  computing 
demands.  (Recall  that  application  computing  demands  vary  from  frame  to 
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Table  4.5.  M.  Experiment  4 Configuration  6 Summary  • Flight  Control  Group 


Phase/ID 

100  Hz 
minumum 
deadline 
margin(ms) 

50  Hz 
minimum 
deadline 
margin(ms) 

25  Hz 
minimum 
deadline 
margin(ms) 

CP 

utilization 

IOP 

utilization 

I/O  system 
utilization 

I/O  network 
utilization 

0 

2.934 

7.007 

15.538 

86% 

72% 

80% 

28% 

1 

2.704 

Missed  7 
deadlines 

10.188 

86% 

72% 

93% 

28% 

2 

2.704 

Missed  7 
deadlines 

10.188 

86% 

72% 

88% 

28% 

3 

2.704 

Missed  7 
deadlines 

10.188 

86% 

72% 

83% 

28% 

4 

3.370 

0.319 

10.320 

86% 

75% 

78% 

28% 

5 

0.508 

1.287 

10.267 

86% 

75% 

84% 

' 28% 

6 

0.653 

7.848 

9.896 

86% 

75% 

79% 

28% 

7 

0.551 

Missed  7 
deadlines 

10.188 

86% 

75% 

92% 

28% 

8 

0.851 

Missed  7 
deadlines 

10.188 

86% 

72% 

91% 

28% 

9 

1.905 

0.625 

11.529 

86% 

73% 

87% 

28% 
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frame  as  the  loop  duration  times  are  modeled  with  a normal  distribution.) 
In  the  other  frames,  the  50  Hz  rate  deadline  is  being  met  with  a very  small 
margin,  illustrating  how  sensitive  the  specific  bad  relative  phasing 
situations  are. 

Of  the  remaining  cases,  phase  4 has  the  largest  deadline  margin  for  the 
100  Hz  rate.  However,  the  50  Hz  rate  is  very  close  to  missing  a deadline. 
Vhile  this  configuration  may  meet  the  minimum  acceptable  requirements,  the 
other  configurations  indicate  that  the  overall  performance  can  be  improved. 
A desirable  goal  is  to  improve  the  minimum  deadline  margin  for  the  50  Hz 
rate  without  a significant  reduction  in  the  100  Hz  minimum  deadline  margin. 
The  best  improvement  for  the  least  reduction  seems  to  occur  with  phase  0. 
The  reduction  in  minimum  deadline  margin  for  the  100  Hz  rate  is  less  than 
0.5  milliseconds.  Additionally,  the  50  Hz  rate's  minimum  deadline  margin 
has  increased  nearly  7 milliseconds  and  the  25  Hz  rate  has  increased  nearly 
5 milliseconds. 

The  time  delay  and  1/0  jitter  data  for  the  phase  0 case  are  illustrated  in 
figure  4.5. 1-1.  Two  spikes,  separated  by  20  microseconds,  are  observed  in 
the  100  Hz  jitter.  The  two  peaks  are  a result  of  the  completion  of  the 
processing  related  to  the  unloading  of  the  network  interfaces  for  the  50  Hz 
in  minor  frames  1 and  3.  This  unloading  completes  nearly  at  the 
beginning  of  minor  frames  2 and  4,  causing  a double  context  switch  at  the 
beginning  of  these  frames  that  slightly  delays  the  execution  of  the  100  Hz 
activity  every  other  frame.  However,  the  resulting  100  Hz  rate  jitter  is  a 
fraction  of  the  update  period.  There  is  no  variation  in  the  start  of  the 
1/0  activity  from  frame  to  frame  for  either  the  50  Hz  or  25  Hz  rate  groups. 

The  effect  of  the  jitter  at  the  start  of  the  100  Hz  1/0  activity  is 
observable  in  the  time  delay  statistics.  It  should  be  pointed  out  that  the 
DIU  response  time  is  modeled  as  a statistical  process  that  results  in  some 
variation  in  the  1/0  completion  time  and  therefore  contributes  to  the  time 
delay  statistics.  The  first  contribution  to  the  100  Hz  time  delay  is  the 
variation  for  the  start  time  of  the  100  Hz  1/0.  The  two  distinct  peaks  are 
a result  of  the  two  distinct  starting  times  for  the  100  Hz  1/0.  The  1/0 
activity  for  the  100  Hz  rate  is  composed  of  eight  transactions.  Each 
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Figure  4.5. 1-1.  Experiment  4 Configuration  6 Phase  0 Application  Performance  Parameters 
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transaction  is  modeled  as  a statistical  process  with  uniform  distribution 
ranging  in  value  between  0 and  10  microseconds.  The  overall  contribution 
of  these  eight  sources  in  the  model  contributes  to  the  bell-shaped 
distribution  about  the  two  peaks  in  the  figure.  The  time  delay  for  the 
50  Hz  and  25  Hz  rates  exhibits  no  unexpected  behavior. 

The  application  sequencing  for  one  major  frame  of  the  preferred 
configuration  (phase  0)  is  illustrated  in  figure  4. 5. 1-2.  This  figure 
illustrates  how  the  application  activity  aligns  with  the  FDIR  to  provide  a 
configuration  that  has  better  performance  than  the  others  evaluated  in  this 
experiment.  In  phase  0,  the  FDIR  is  scheduled  to  execute  1 millisecond 
into  the  minor  frame.  This  allows  a small  degree  of  parallel  activity  in 
our  model  because  the  100  Hz  1/0  activity  can  be  executing  using  the  IOSs 
and  DIUs  while  the  FDIR  is  executing  on  the  I0P. 

Engine  Control  Group 

The  workload  on  the  engine  control  group  is  substantially  less  demanding 
than  that  on  the  flight  control  functions.  Consequently,  the  engine 
control  computer  is  able  to  meet  the  deadlines  of  the  engine  control 
functions  in  all  the  1/0  scheduling  and  1/0  grouping  alternatives.  Details 
for  each  configuration  will  be  presented  in  the  following  paragraphs. 

Configuration  14  (On  Demand  Grouped  I/O  Organization).  The  deadline 
margins  and  utilization  values  for  configuration  14  are  illustrated  in 
table  4.5. 1-2.  The  minimum  deadline  margin  data  from  this  experiment 
indicates  that  all  the  phasing  options  have  adequate  reserve  margins. 
These  values  are  significantly  better  than  those  of  the  flight  control 
group,  reflecting  the  difference  in  the  workload  demands. 

No  configuration  has  clearly  superior  performance  characteristics. 
Therefore,  the  phase  4 case  is  selected  as  the  preferred  configuration 
based  on  the  largest  minimum  deadline  margin  for  all  the  application  rates. 
The  1/0  jitter  and  time  delay  characteristics  for  this  configuration  are 
illustrated  in  figure  4.5. 1-3.  The  100  Hz  rate  exhibits  what  appear  to  be 
uniformly  varying  start  times  over  an  approximate  range  of  15  microseconds. 
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Table  4.5. 1-2.  Experiment  4 Configuration  14  Summary 


Phase/ID 

100  Hz 
minimum 
deadline 
margin(ms) 

50  Hz 
minimum 
deadline 
margin(ms) 

25  Hz 
minimum 
deadline 
margin(ms) 

CP 

utilization 

I0P 

utilization 

I/O  system 
utilization 

I/O  network 
utilization 

0 

5.657 

13.598 

31.941 

51% 

53% 

57% 

7% 

1 

6.440 

14.898 

33.241 

48% 

58% 

46% 

7% 

2 

6.440 

14.898 

33.241 

48% 

58% 

46% 

7% 

3 

6.440 

14.898 

33.241 

48% 

58% 

46% 

7% 

4 

7.140 

15.560 

33.241 

51% 

58% 

39% 

7% 

5 

7.140 

15.560 

31.341 

51% 

58% 

39% 

7% 

6 

7.140 

12.998 

31.341 

51% 

58% 

39% 

7% 

7 

7.140 

13.298 

31.641 

51% 

56% 

56% 

7% 

8 

4.540 

14.041 

32.384 

51% 

56% 

50% 

7% 

9 

4.840 

12.598 

30.941 

51% 

55% 

67% 

7% 
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Figure  4.5. 1-3.  Experiment  4 Configuration  14  Phase  4 Application  Performance  Parameters 


This  is  characteristic  of  the  uniformly  distributed  models  for  the  response 
to  an  interprocessor  event  used  in  the  on  demand  I/O  option.  This 
characteristic  is  not  visible  in  either  the  50  Hz  or  25  Hz  I/O  because  the 
100  Hz  I/O  is  executing  when  these  requests  are  made.  The  time  delay  data 
for  the  preferred  configuration  are  acceptable. 

A timeline  of  one  major  frame  for  the  phase  4 case  is  illustrated  in  figure 

4.5. 1- 4.  Note  that  the  50  Hz  or  25  Hz  I/O  activity  is  loaded  during  the 
I0P  idle  time  before  unloading  the  100  Hz  data  during  the  appropriate  minor 
frames.  This  "preloading"  does  not  occur  in  the  preferred  flight  control 
configuration  because  the  FDIR  executes  during  the  100  Hz  I0S  execution. 

The  phase  4 case  could  have  problems  when  future  growth  is  considered.  In 
this  situation,  the  FDIR  executes  at  the  end  of  every  minor  frame,  after 
the  completion  of  all  application  activity.  The  simple  minimum  deadline 
margin  figure  of  merit  of  7.140  milliseconds  may  be  misleading  in  this 
situation.  Because  the  FDIR  executes  after  the  application  activity,  the 
application  cannot  expand  to  fill  the  7.140  milliseconds  without  being 
preempted  by  the  FDIR.  A more  sophisticated  measure  of  deadline  margin 
might  be  necessary  to  allow  better  comparison  in  such  situations. 

Configuration  15  (On  Demand  Separated  1/0  Organization).  The  deadline 
margins  and  utilization  values  for  configuration  15  are  shown  in  table 

4.5. 1- 3.  No  data  are  available  for  phases  1,  2,  3,  7,  and  8 because  a 
simulation  error  prevented  correct  modeling  of  the  overrun  policy.  The 
minimum  deadline  margins  for  this  configuration  are  smaller  than  those  from 
configuration  14. 

The  phase  6 case  is  selected  as  the  preferred  configuration  based  on  the 
criterion  that  it  maximizes  the  minimum  deadline  margin  for  all  application 
rates.  The  jitter  characteristics  for  the  input  and  output  1/0  activity 
and  the  time  delay  data  are  shown  in  figure  4.5. 1-5. 

The  output  jitter  histogram  for  the  100  Hz  rate  shows  two  peaks  separated 
by  approximately  3 milliseconds.  Unlike  previous  situations,  the  variation 
is  a significant  portion  of  the  minor  frame  period.  A closer  look  at  each 
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Table  4.5. 1-3.  Experiment  4 Configuration  15  Summary 


Phase/ID 

100  Hz 
minimum 
deadline 
margin(ms) 

50  Hz 
minimum 
deadline 
margin(ms) 

25  Hz 
minimum 
deadline 
margin(ms) 

CP 

utilization 

IOP 

utilization 

I/O  system 
utilization 

I/O  network 
utilization 

0 

4.134 

9.996 

19.867 

51% 

84% 

96% 

7% 

1 

No  data  available 

2 

3 

4 

5.146 

9.889 

29.037 

50% 

87% 

93% 

7% 

5 

6.144 

11.647 

28.612 

51% 

86% 

94% 

7% 

6 

6.144 

11.998 

29.337 

51% 

86% 

95% 

7% 

7 

No  data  available 

8 

9 

4.743 

12.300 

30.680 

51% 

87% 

97% 

7% 
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Figure  4.5. 1-5  Experiment  4 Configuration  15  Phase  6 Application 
Performance  Parameters  (Sheet  1 of  2) 
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Figure  4.5. 1-5.  Experiment  4 Configuration  15  Phase  6 Application 
Performance  Parameters  (Sheet  2 of  2) 


peak  of  the  100  Hz  output  jitter  is  shown  in  figure  4.5. 1-6.  The  first 
peak  reduces  to  what  appears  to  be  a uniform  distribution  with  a range  of 
16  microseconds.  This  shape  and  range  are  attributed  to  the  system  being 
idle  when  this  I/O  request  is  made.  This  situation  happens  most  often  in 
minor  frame  4,  when  only  the  100  Hz  process  executes.  A more  detailed 
investigation  of  the  second  group  shows  that  it  is  composed  of  two  separate 
distributions.  One  distribution  is  clustered  at  7.600  milliseconds  and  the 
other  appears  to  be  uniformly  distributed  between  7.715  milliseconds  and 
7.731  milliseconds.  The  first  cluster  is  associated  with  1/0  requests  that 
have  been  preloaded,  while  the  second  distribution  is  associated  with  1/0 
requests  that  are  serviced  by  an  idle  I/O  system.  A timeline  of  the 
selected  configuration  is  shown  in  figure  4.5. 1-7. 

Configuration  16  (Scheduled  Grouped  I/O  Organization).  The  deadline 
margins  and  utilization  values  for  configuration  16  are  shown  in  table 
4.5. 1_4.  These  values  do  not  differ  significantly  from  the  on  demand- 
grouped  1/0  configuration.  One  minor  difference  is  in  the  minimum  deadline 
margins  for  phasing  cases  1,  2,  and  3.  These  values  are  1 millisecond  or 
more  larger  than  the  on  demand  grouped  1/0  configuration.  This  is  because 
the  start  of  frame  occurs  in  the  I0P  instead  of  the  CP.  This  eliminates 
the  extra  overhead  step  of  waking  up  the  CP  just  to  start  the  1/0  activity 
in  the  I0P.  The  earlier  start  of  the  1/0  activity  causes  the  1/0 
completion  poll  to  be  scheduled  1 millisecond  earlier  in  the  frame. 

The  phase  3 case  is  selected  as  the  preferred  configuration  because  it  has 
the  lowest  10  service  utilization.  The  I/O  jitter  and  the  time  delay 
characteristics  for  the  phase  3 case  are  illustrated  in  figure  4.5. 1-8. 
The  1/0  jitter  and  the  time  delay  histograms  reveal  nothing  unexpected. 
The  timeline  for  one  major  frame  of  the  preferred  configuration  is 
illustrated  in  figure  4.5. 1-9. 

Experiment  4 shows  that  the  phasing  of  the  FDIR  and  the  application  is 
critical,  especially  in  heavily  loaded  cases.  An  implementation  technique 
will  be  needed  to  control  the  relative  execution  phasing  of  the  FDIR 
process  and  the  application.  Additionally,  the  simulation  showed  that  the 
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Table  4.5. 1-4.  Experiment  4 Configuration  16  Summary 


Phase/ID 

100  Hz 
minimum 
deadline 
margin(ms) 

50  Hz 
minimum 
deadline 
margin(ms) 

25  Hz 
minimum 
deadline 
margin{ms) 

CP 

utilization 

IOP 

utilization 

I/O  system 
utilization 

I/O  network 
utilization 

0 

5.841 

13.815 

32.192 

42% 

53% 

60% 

7% 

1 

7.440 

16.115 

34.492 

42% 

55% 

62% 

7% 

2 

7.441 

16.115 

34.492 

42% 

55% 

52% 

7% 

3 

7.141 

16.115 

34.492 

42% 

55% 

42% 

7% 

4 

7.140 

15.815 

34.192 

42% 

58% 

42% 

7% 

5 

7.140 

15.815 

31.592 

42% 

58% 

42% 

7% 

6 

7.140 

13.215 

31.592 

42% 

58% 

42% 

7% 

7 

7.140 

13.515 

m pj 

42% 

56% 

59% 

7% 

8 

4.540 

14.258 

32.635 

42% 

56% 

54% 

7% 

9 

4.840 

12.815 

31.192 

42% 

55% 

70% 

7% 
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Figure  4.5. 1-9.  Experiment  4 Configuration  16  Phase  3 Case 
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system  loading  was  more  severe  than  indicated  by  the  manual  estimates, 
which  could  not  cover  resource  contention  and  neglected  task  sequencing  and 
control  overhead. 

4.5.2  Utilization  (Experiment  5) 

The  utilization  of  four  key  resources  was  measured  during  the  experiment 
4 runs.  The  resources  were  the  CP,  IOP,  I/O  system,  and  the  I/O  network. 
In  this  way  the  objectives  of  experiment  5 were  met  without  making  any 
dedicated  experiment  runs.  Before  discussing  the  results,  some 
peculiarities  of  the  I/O  system  and  the  I/O  network  utilization  parameters 
are  described  in  greater  detail. 

The  I/O  system  utilization  is  a measure  of  the  availability  of  the  I/O 
system  to  accommodate  additional  I/O  demands.  The  I/O  system  values  can 
vary  somewhat  according  to  how  utilization  is  accounted  for.  Some  PDIR 
application  phasings  result  in  scheduling  an  I/O  completion  poll  (see 
section  4.4.2)  at  the  same  time  the  FDIR  is  scheduled  to  execute.  When 
this  happens  the  FDIR  executes  in  the  IOP,  because  it  has  higher  priority. 
The  I/O  completion  poll  processing  is  delayed  until  the  completion  of  the 
FDIR,  which  results  in  busy  time  counted  against  the  I/O  system  even  though 
no  I/O  activity  is  being  accomplished.  With  slightly  different  phasing 
alignments  this  I/O  completion  delay  does  not  occur  and  is  not  counted  as 
utilization. 

The  I/O  network  utilization  measures  the  time  that  the  network  is  dedicated 
to  performing  application  I/O.  This  includes  the  time  from  the  beginning 
of  the  transmission  of  the  first  transaction  in  the  I/O  activity  until  the 
IOS  has  completed  processing  the  last  transaction  in  the  activity.  The 
IAPSA  study  results  revealed  that  a small  utilization  value  for  the  I/O 
network  is  not  necessarily  a good  indicator  of  spare  I/O  capacity.  This  is 
because  the  I/O  network  use  is  only  a small  portion  of  the  end-to-end  time 
requirement  for  performing  an  I/O  request.  The  I/O  system  utilization 
value  appears  to  be  a better  indicator  of  the  effect  of  the  application 
workload  on  the  I/O  resources  for  this  implementation. 
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Flight  Control  Group 


The  utilization  of  the  system  elements  for  configuration  6 is  shown  in 
table  4.5. 1-1.  The  values  are  generally  high,  with  the  exception  of  the 
I/O  network.  The  utilization  of  the  CP  is  86%.  The  utilization  of  the  IOP 
is  between  72%  and  75%.  The  utilization  measures  for  the  preferred 
candidate  (phase  0)  do  not  meet  the  100%  growth  capability  requirement. 

Engine  Control  Group 

Configuration  14  (On  Demand  Grouped  I/O  Organization).  The  utilization 
figures  are  shown  in  table  4.5. 1-2.  Three  phasing  cases  result  in  the 
lowest  CP  utilization  (phase  1,  2,  and  3).  This  is  because  these  phasings 
have  one  less  process  switch  per  minor  frame  than  all  the  other  phasings. 
The  IOP  utilization  ranges  from  53%  to  58%.  As  the  scheduled  time  for  FDIR 
moves  through  the  minor  frame,  different  sequences  of  processing  occur. 
The  wide  range  in  I/O  system  utilization  is  attributed  to  the  accounting 
method  characteristics  described  previously.  That  is,  if  the  FDIR 
interferes  with  the  processing  for  I/O  activity,  the  PDIR  processing  time 
is  counted  against  the  I/O  system.  The  I/O  network  utilization  is  well 
within  the  system  capacity  limits. 

Configuration  15  (On  Demand  Separated  I/O  Organization).  The  data  for  this 
configuration  are  presented  in  table  4.5. 1-3.  The  utilization  of  the  CP  is 
essentially  unchanged  from  other  configurations.  However,  the  IOP 
utilization  has  jumped  significantly.  The  cause  is  the  separation  of  the 
I/O  activity  into  two  activities  per  rate  group  per  control  cycle.  When 
the  I/O  is  divided  into  two  activities  per  rate  group,  the  overhead 
associated  with  I/O  request  execution  doubles.  This  has  an  adverse  effect 
on  I/O  system  utilization  resulting  in  essentially  no  reserve  capacity 
remaining  in  this  configuration. 

Configuration  16  (Scheduled  Grouped  I/O  Organization).  The  utilization 
values  for  configuration  16  are  shown  in  table  4.5. 1-4.  Because  the  start 
of  frame  event  occurs  in  the  IOP,  the  CP  utilization  values  are  smaller 
than  in  the  on  demand  grouped  I/O  configuration  (configuration  14). 
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4.5.3  I/O  Scheduling  (Experiment  3) 


The  purpose  of  this  experiment  is  to  evaluate  the  effect  of  the  I/O 
scheduling  mechanism  on  the  performance  of  the  application  during  normal 
operation.  In  addition  a single  representative  configuration  will  be 
selected  for  the  engine  and  flight  control  groups  to  serve  as  a baseline 
for  the  I/O  link  fault  experiments.  No  special  runs  were  made  to  obtain 
data  for  this  experiment.  all  needed  information  was  gathered  during 
experiment  4 runs. 

Flight  Control  Group 

As  discussed  in  section  4.5.1,  only  the  scheduled  grouped  I/O  organization 
option  (configuration  6)  could  support  the  workload  of  the  flight  control 
group.  The  resulting  performance  for  the  preferred  phasing  option  is 
summarized  in  table  4. 5. 3-1. 

Engine  Control  Group 

The  performance  of  the  preferred  configurations  for  the  engine  control 
group  from  experiment  4 are  summarized  in  table  4. 5. 3-1.  All  engine 
control  configurations  appear  to  have  adequate  deadline  margin.  The  CP 
utilization  is  satisfactory  in  all  configurations.  The  IOP  utilization  is 
satisfactory  except  for  the  on  demand  separated  I/O  option  (configuration 
15).  For  experiment  2,  a representative  single  configuration  is  chosen  for 
the  engine  control  group.  The  on  demand  grouped  I/O  option  (configuration 
G4)  is  selected  as  the  I/O  scheduling  mechanism  for  the  engine  control 
computer. 


4.5.4  I/O  Link  Failure  (Experiment  2) 

The  purpose  of  experiment  2 is  to  measure  the  time  needed  to  successfully 
return  a faulty  network  to  service.  In  addition,  the  experiment  evaluates 
the  effect  of  the  repair  processing  on  application  performance.  The 
out-of-service  time  measures  the  time  between  a network  being  taken 
out-of-service  for  repair  and  the  time  the  network  manager  returns  a 
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Table  4.5. 3-1.  Summary  I/O  Scheduling 


Engine  Control  Computer 

100  Hz 

50  Hz 

25  Hz 

Minimum 

Minimum 

Minimum 

I/O 

Deadline 

Deadline 

Deadline 

CP 

IOP 

System 

Margin  (ms) 

Margin  (ms) 

Margin  (ms) 

Utilization 

Utilization 

Utilization 

On  demand/grouped 

7.140 

15.598 

33.941 

51% 

58% 

39% 

On  demand/separated 

11.998 

29.337 

51% 

86% 

95% 

Scheduled/grouped 

7.440 

16.115 

34.492 

42% 

55% 

42% 

Flight  Control  Computer 

100  Hz 

50  Hz 

25  Hz 

Minimum 

Minimum 

Minimum 

I/O 

Deadline 

Deadline 

Deadline 

CP 

IOP 

System 

Margin  (ms) 

Margin  (ms) 

Margin  (ms) 

Utilization 

Utilization 

Utilization 

Scheduled/grouped 

2.934 

7.007 

15.538 

86% 

72% 

80% 
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network  to  service.  A key  concern  in  this  experiment  is  the  change  in  the 
application  timing  characteristics  due  to  the  I/O  network  repair  activity. 
Second , the  out-of-service  time  must  be  compared  to  the  1 second  fault 
recovery  period  used  in  the  initial  reliability  analysis.  Experiment  2 
faults  were  inserted  at  a random  time  relative  to  the  major  frame  for  each 
run.  For  each  link  the  experiment  was  repeated  50  times. 

One-Shot  Repair  Strategy  Experiments 

Flight  Control  Group  (Configuration  11).  The  I/O  network  out-of-service 
time  distributions  for  this  experiment  are  summarized  in  figure  A. 5. 4-1. 
Two  factors  drive  the  resulting  distribution.  First,  the  detection  of  a 
fault  is  dependent  on  the  topology  of  the  network.  Second,  the  detection 
of  the  fault  by  the  application  I/O  activity  is  dependent  on  the  time  of 
application  I/O  execution.  The  network  topology  aspect  is  illustrated  in 
figure  4. 5. 4-2.  Network  2 is  shown  as  it  is  grown  at  power-up  with  no 
faults.  The  stars  contained  in  each  node  indicate  the  application  I/O 
activity  rate  groups  that  are  dependent  on  the  inboard  link  on  that  node. 


Note  that  several  of  the  link  failures  can  be  detected  by  communication 
faults  appearing  in  more  than  one  application  I/O  activity.  This  is 
because  either  the  attached  DIU  or  the  downstream  DIUs  are  accessed  by  more 
than  one  application  rate  group's  I/O  activity.  One  example  is  DIU  CP3, 
which  is  accessed  by  both  the  50  Hz  rate  and  the  25  Hz  rate  I/O  activity. 
Another  example  is  DIU  RR,  which  is  accessed  by  the  50  Hz  rate,  while  its 
downstream  node,  TER,  is  accessed  by  the  100  Hz  1/0  activity.  Therefore, 
when  the  link  that  connects  RR  to  FC4  fails,  either  the  100  Hz  1/0  or  the 
50  Hz  1/0  activity  will  result  in  communication  failures. 

There  are  seven  application  1/0  completion  polls  per  major  frame  for  the 
grouped  1/0  organization  configurations.  Therefore  there  are  seven 
discrete  times  in  a major  frame  that  a fault  can  be  detected.  A particular 
fault  may  only  be  discovered  by  the  50  Hz  1/0  activity  and  thus  have  only 
two  opportunities  for  detection  per  major  frame.  A fault  that  is  detected 
by  both  the  100  Hz  and  the  50  Hz  1/0  activities  has  six  detection 
opportunities  per  major  frame. 
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Figure  4.5.4-1.  Out  of  Service  Time  For  One  Shot  Repair  - Flight  Control  Computer  (Sheet  2 of  3) 
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Network  repair  activity  consists  of  a sequence  of  processing  and  I/O 
request  steps  to  repair  a passive  I/O  link  failure.  The  network  manager  is 
responsible  for  implementing  the  repair  strategy.  It  executes  in  idle  time 
on  the  IOP  since  its  priority  is  less  than  the  application  I/O  activity. 
The  application  activity  in  the  IOP  is  relatively  constant;  the  idle  time 
slots  therefore  align  themselves  to  positions  in  the  major  frame.  The 
repair  steps  are  accomplished  during  these  idle  periods.  The  I/O 
completion  poll  activity  that  detects  the  communication  fault  determines 
the  initial  phasing  of  the  I/O  repair  activity  relative  to  the  major  frame. 
The  initial  phasing,  coupled  with  the  sequence  of  idle  time  slots  available 
in  the  IOP  control,  governs  the  out-of-service  time. 


The  number  of  distinct  out-of-service  times  depends  primarily  on  the  unique 
combinations  of  initial  phasings  and  sequences  of  IOP  idle  time. 
Variability  of  IOP  processing  can  also  have  an  effect.  A link  failure 
between  node  75  and  76  is  only  detected  by  the  100  Hz  I/O  activity.  There 
are  four  unique  repair  times  corresponding  to  faults  detected  by  100  Hz  I/O 
activity.  However,  there  is  only  one  unique  time,  longer  than  any  of  the 
100  Hz  repair  times  for  link  failures  detected  by  the  50  Hz  rate.  This  is 
seen  in  the  histogram  for  link  failures  between  node  71  and  node  72  on 
sheet  1 of  figure  4. 5.4-1.  There  is  also  a unique  repair  time,  shorter 
than  any  other,  for  failures  detected  by  the  25  Hz  activity. 

The  link  failures  that  are  detected  by  more  than  one  1/0  activity  result  in 
out-of-service  times  that  are  a combination  of  the  results  for  the 
individual  rates.  This  is  observed  in  the  data  for  link  failures  between 
nodes  71  and  75,  which  are  detected  by  the  100  Hz  and  50  Hz  application  1/0 
activity,  and  failures  between  nodes  87  and  86,  which  are  detected  by  the 
50  Hz  and  25  Hz  1/0  activity.  This  discussion  illustrates  that  the  results 
of  the  random  testing  can  often  be  related  to  the  details  of  system 
operation. 

A summary  of  the  application  performance  measures  for  each  link  failure 
sequence  is  illustrated  in  table  4. 5. 4-1.  The  CP  utilization  is  not 
included  in  the  summary  because  it  is  not  affected  by  the  network  repair 
activity.  In  addition,  the  1/0  network  utilization  is  not  included  because 
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it  is  not  affected  on  the  "good"  network,  while  the  repair  activity  has 
exclusive  use  of  the  failed  network.  Some  significant  differences  are 
observed  when  comparing  table  4. 5. 4-1  to  the  normal  flight  control  group 
results  in  table  4. 5. 3-1.  First,  the  minimum  deadline  margin  of  the  50  Hz 
rate  has  been  reduced  from  more  than  7 milliseconds  to  approximately 
2.5  milliseconds.  Second,  the  utilization  of  the  I0P  has  increased 
slightly  while  the  I/O  service  utilization  has  been  reduced  from  80  percent 
to  68  percent. 


Figure  4. 5. 4-3  is  a timeline  of  processes  for  the  CP,  I0P,  and  I/O  networks 
as  they  occurred  in  the  33  repetitions  of  the  experiment  simulating  a link 
failure  between  nodes  72  and  73.  The  second  major  frame  shown  in  the  top 
part  of  the  figure  illustrates  the  alignment  of  processes  during  normal 
operation.  At  67.1  milliseconds  the  link  between  nodes  72  and  73  is 
failed.  This  link  is  used  exclusively  by  the  50  Hz  I/O  activity.  The 
failure  occurs  during  the  second  50  Hz  I/O  activity  in  this  major  frame  but 
the  transaction  that  uses  the  failed  link,  so  the  failure  is  not 
[discovered  until  the  next  50  Hz  1/0  activity. 

The  I/O  link  failure  is  detected  in  the  third  major  frame  illustrated  in 
the  bottom  part  of  the  figure.  Network  2 is  taken  out  of  service  when  the 
50  Hz  1/0  completion  poll  processing  discovers  the  communication  faults. 
The  effects  of  this  action  are  immediately  observed  in  the  second  minor 
frame.  The  load  time  for  the  1/0  activity  is  reduced  by  50  percent  because 
network  2 is  out  of  service.  When  a network  is  taken  out  of  service,  the 
reduction  in  pre-  and  post-processing  needs  in  the  I0P  results  in  a new 
alignment  application  1/0  processing. 

As  a result  of  network  2 being  taken  out  of  service,  the  25  Hz  1/0  activity 
starts  on  the  network  earlier.  This  earlier  start  has  two  causes.  First, 
loading  activity  for  the  25  Hz  data  rate  fits  into  the  new  idle  time  slot 
just  before  the  FDIR  processing  (preloading).  Second,  the  100  Hz  1/0 
activity  unloading  time  is  reduced. 


At  approximately  95  milliseconds,  the  first  I0P  idle  slot  occurs  and  the 
repair  activity  for  network  2 starts.  The  first  step  in  this  process  is  to 
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attempt  communication  with  all  the  nodes  in  network  2,  as  seen  by  the  long- 
duration  I/O  activity  on  the  network  2 line. 

The  reduced  minimum  deadline  margin  for  the  50  Hz  rate  group  is  a result  of 
the  new  idle  time  slot  in  the  I0P  after  the  completion  of  the  100  Hz  I/O 
loading.  When  this  new  idle  time  slot  occurs  in  the  third  minor  frame,  the 
50  Hz  data  loading  starts  during  the  gap.  The  deadline  for  the  50  Hz  rate 
group  is  the  start  of  1/0  data  loading.  One  effect  of  taking  the  network 
out  of  service  is  a forward  shift  of  the  50  Hz  computing  deadline  by 

5 milliseconds. 

The  overall  50  Hz  deadline  margin  effect  is  a reduction  for  the  one 
‘ transition  frame  when  the  deadline  moves  earlier  by  5 milliseconds.  The 
new  minimum  deadline  margin  is  2.5  milliseconds  for  the  50  Hz  rate  group. 
However,  because  the  computing  completion  immediately  moves  forward  as  the 
activity  in  the  CP  adjusts  itself  to  the  new  alignment  of  events  in  the 
I0P,  the  deadline  margin  jumps  to  a larger  value  for  the  remainder  of  the 
repair  period.  Thus  the  minimum  value  sample  occurs  in  the  transition 
frame  in  all  of  the  failure  simulations. 

The  repair  activity  in  the  I0P  and  on  the  network  continues  throughout  the 
remainder  of  this  major  frame  and  completes  in  the  first  minor  frame  shown 
in  major  frame  4.  The  last  processing  element  of  the  repair  activity 

returns  network  2 to  service  during  the  execution  of  the  50  Hz  1/0.  When 
network  2 is  returned  to  service,  the  processing  elements  in  the  I0P 
realign  to  the  positions  they  occupied  before  the  fault.  The  return  of 
these  processing  elements  to  their  former  positions  triggers  a new  CP 
processing  alignment  which  returns  the  processing  elements  to  their 
positions  before  the  network  failure. 

Figure  4. 5. 4-4  illustrates  the  other  two  application  performance  measures 
during  1/0  network  repair.  Data  are  presented  for  all  50  repetitions  of 
the  experiment.  The  data  for  both  measures  include  samples  when  both 
networks  are  in  service  as  well  as  when  only  one  network  is  in  service. 
Some  of  the  1/0  jitter  samples  reflect  the  earlier  start  of  activity  when 
only  one  network  is  in  service.  The  time  delay  data  include  samples  from 
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Frequency  Frequency  Frequency 


the  transition  frames  when  a network  is  taken  out  of  service  and  is  put 
back  in  service.  In  both  situations  the  relative  frame  time  of  the  I/O 
activity  event  shifts,  resulting  in  an  unusually  large  or  small  value  for 
time  delay  for  the  transition  frame. 

Engine  Control  Group  (Configuration  13).  The  I/O  network  out  of  service 
times  for  this  configuration  are  shown  in  figure  4. 5. 4-5.  Network  2 is 
illustrated  in  figure  4. 5. 4-6  as  it  is  grown  with  no  link  failures.  The 
out-of-service  times  for  this  configuration  are  approximately 

20  milliseconds  with  the  exception  of  root  link  failures  which  take  less 
than  10  milliseconds.  These  times  are  faster  than  the  flight  control 
configuration  because  there  is  more  idle  I0P  capacity  to  perform  repair 

activity. 

A summary  of  the  deadline  margin  and  utilization  data  for  each  link  failure 
is  shown  in  table  4. 5. 4-2.  One  difference  in  the  data  for  this 
configuration  and  the  flight  control  computer  is  that  the  minimum  deadline 
margins  were  not  significantly  affected  by  the  I/O  network  repair  activity. 
When  a network  is  taken  out  of  service,  the  application  processing  elements 
do  not  significantly  realign.  One  reason  for  this  is  that  the  processing 
demands  on  the  I0P  are  very  light.  A timeline  of  the  repair  activity  from 
the  21st  repetition  of  link  failure  between  node  70  and  71  is  shown  in 
figure  4. 5. 4-7. 

The  remaining  application  performance  measures  during  repair  are 
illustrated  in  figure  4. 5. 4-8. 

Regrov  Repair  Strategy  Experiments 

The  one-shot  repair  strategy  is  able  to  diagnose  and  repair  only  a few 
active  network  failures.  A check  is  made  to  uniquely  identify  failures 
such  as  an  inboard  babbling  port  and  to  select  the  proper  repair  actions. 
However,  other  failures  such  as  an  outboard  babbling  link  will  have  the 
same  symptoms  as  a passively  failed  link.  The  repair  of  an  outboard 
babbler  that  is  diagnosed  as  a passive  link  failure  changes  the  babbler's 
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Table  4.5.4-2.  Experiment  2 Configuration  13  Summary 


Failed  link 
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Time  delay 


orientation  to  inboard,  causing  loss  of  communication  with  the  entire 
network.  The  inability  to  correctly  identify  this  failure  results  in 
wasted  repair  actions  and  prolonged  out-of-service  times. 

This  experiment  measures  the  duration  of  network  repair  activity  when  a 
full  regrow  strategy  is  invoked.  This  is  a reasonable  approximation  of  the 
repair  time  for  active  failures,  because  repair  sequences  that  do  not  show 
progress  must  be  abandoned  and  a more  time-consuming  regrow  action  used  to 
guarantee  a working  network. 

Flight  Control  Group  (Configuration  10).  The  I/O  network  out-of-service 
times  for  this  experiment  are  shown  in  figure  A. 5. 4-9.  The  significant 
difference  between  this  repair  strategy  and  the  one-shot  strategy  is  that 
the  out-of-service  times  are  substantially  larger.  The  repair  times  for 
this  experiment  slightly  exceed  the  1 second  value  used  in  the  reliability 
analysis. 

Some  application  performance  measures  are  summarized  in  table  4. 5. 4-3,  and 
the  I/O  jitter  and  time  delay  data  are  shown  in  figure  4.5.4-10.  The  shift 
in  performance  characteristics  during  repair  is  similar  to  those  occurring 
in  the  one-shot  experiment.  The  number  of  values  in  the  bins  corresponding 
to  ongoing  repair  are  greater  because  of  the  long  duration  of  the  full 
regrow  repair. 

Engine  Control  Group  (Configuration  12).  The  out-of-service  times  for  this 
experiment  are  shown  in  figure  4.5.4-11.  The  full  regrow  strategy  requires 
significantly  more  time  than  the  one-shot  repair  strategy  for  the  engine 
control  group.  A summary  of  the  application  performance  is  presented  in 
table  4. 5. 4-4.  Histograms  of  the  I/O  jitter  and  time  delay  data  are  shown 
in  figure  4.5.4-12. 

4.6  Experiment  Observations 

During  performance  analysis  a sequence  of  experiments  is  performed  to 
evaluate  normal  and  failed  operation  of  a candidate  system  and  to  evaluate 
critical  performance  issues.  The  order  of  experiments  is  determined  by  the 
performance  analyst  and  depends  on  factors  such  as  modeling  detail  needed 
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Figure  4.5. 4-9.  Out  of  Service  Time  For  Regrow  Repair  Flight  Control  Computer  (Sheet  1 of  3) 
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Figure  4.5.4- 1 1.  Out  of  Service  Time  for  Regrow  Repair  Engine  Control  Computer 
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Table  4.5.4-4.  Experiment  2 Configuration  13  Summary 


Failed  link 

100  Hz 
minimum 
deadline 
margin(ms) 

50  Hz 
minimum 
deadline 
margin(ms) 

25  Hz 
minimum 
deadline 
margin(ms) 

IOP 

utilization 

I/O  system 
utilization 

28-70 

7.141 

15.598 

34.022 

59% 

39% 

70-71 

7.040 

14.749 

33.078 

63% 

38% 

70-72 

7.142 

15.595 

33.989 

64% 

38% 

70-73 

7.147 

15.448 

33.996 

63% 

39% 
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Figure  4.5.4-12.  Experiment  2 Configuration  12,  Link  70-71,  Application  Performance  Parameters 
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for  the  experiment,  how  close  the  candidate  is  to  satisfying  the 
application  requirements,  time  available  to  pursue  alternate  design 
options,  etc.  It  is  expected  that  during  the  evaluation  of  a candidate, 
some  performance  requirements  will  not  be  satisfied  and  refinements  or  a 
new  design  will  be  needed.  Our  approach  in  this  situation  was  to  complete 
the  entire  set  of  experiments  and  use  all  results  before  modifying  the 
system. 

It  was  obvious  at  the  conclusion  of  experiment  4 that  the  candidate 
architecture  could  not  meet  the  growth  capability  performance  requirement. 
However,  experiment  2 was  completed  before  refining  the  candidate  design  to 

obtain  insight  into  the  candidate's  operating  characteristics  under 
failure. 

As  discussed  earlier,  one  characteristic  of  the  io  service  model  developed 
during  the  performance  modeling,  is  that  lower  priority  I/O  data  can  be 
preloaded  when  higher  priority  I/O  activity  is  being  executed  by  the  IOS. 
It  is  not  clear  whether  the  overall  effect  was  beneficial.  Additional 
complexity  in  the  I/O  system  service  software  is  required  to  support  this 
capability.  It  was  thought  that  preloading  might  improve  application 

performance  for  heavily  loaded  configurations  such  as  the  flight  control 
computer. 

However,  preloading  did  not  occur  during  normal  operation  in  the  selected 
flight  control  configuration.  It  happened  only  when  a network  was  taken 
out  of  service  for  repair.  As  a result,  the  deadline  margin  for  the  50  Hz 
rate  was  substantially  reduced  for  one  cycle  because  preloading  occurred  in 
the  new  idle  time  slot  before  FDIR  execution.  Here  the  preloading  effect 
was  negative.  Since  the  interactions  can  be  subtle,  there  is  a definite 
benefit  to  a detailed  simulation  when  considering  sequencing  and  control 
alternatives  in  a candidate  architecture. 


Preloading  was  used  during  normal  operation  of  the  selected  engine  control 
configuration.  However,  it  was  "lightly"  loaded  and  the  performance 
benefit  was  minimal. 
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The  modeled  priority  scheme  for  the  10  service  processing  in  the  I0P  may 
inhibit  better  application  performance  in  some  configurations.  There  are 
several  configurations  in  experiment  4 in  which  lower  priority  output  data 
was  preloaded  before  execution  of  a higher  priority  I/O  completion  poll. 
Since  the  preloaded  I/O  request  is  lower  priority,  the  high-priority  I/O 
data  are  unloaded  before  starting  the  preloaded  I/O  request.  This  occurred 
in  the  engine  control  group  at  the  100  Hz  I/O  completion  poll,  with  a 
preloaded  50  Hz  I/O  request.  Since  the  time  to  unload  the  100  Hz  data  was 
approximately  1.4  milliseconds,  the  50  Hz  1/0  execution  was  delayed  by  this 

amount . 


An  alternative  policy  would  be  to  start  the  preloaded  1/0  activity  and  then 
begin  to  unload  the  higher  priority  1/0  data.  This  would  delay  the 
unloading  of  the  100  Hz  data  by  one  task  process  switch  and  the  time  needed 
to  start  I0S  execution,  but  would  begin  the  execution  of  the  50  Hz  1/0 
nearly  2 milliseconds  earlier.  This  rule  allows  additional  concurrency  and 
would  significantly  improve  the  50  Hz  rate  group  deadline  margin  with 
minimal  impact  on  the  100  Hz  rate  group.  This  illustrates  the  benefits  of 
the  performance  simulation  in  that  the  direct  effects  and  any  unintended 
side  effects  on  the  application  of  operating  rule  changes  can  be  determined 
easily.  Furthermore,  the  interaction  between  the  application  and  system 
features  can  be  tuned  early  in  the  design  cycle. 


During  normal  operation,  the  preemptive  priority  scheduler  proved  useful  by 
ensuring  that  the  processor  was  allocated  to  the  task  with  the  smallest 
execution  deadline.  Additionally,  during  1/0  network  repair  the  preemptive 
priority  scheduler  allowed  the  I0P  to  perform  network  repair  activity  when 
no  application  activity  was  ready.  This  has  the  effect  of  coordinating  the 
processing  associated  with  the  1/0  network  repair  with  the  application- 
related  processing  on  an  as-needed  basis. 


One  concern  with  preemptive  priority  schedulers  that  surfaced  during  the 
experiments  is  that  they  can  introduce  variability  in  the  execution  of  some 
I0P  processes  whose  effects  propagated  to  other  parts  of  the  system.  This 
occurred  during  repair  in  both  the  flight  control  computer  and  the  engine 
control  computer.  The  variability  arose  .hen  two  processes  became  ready  to 


223 


execute  at  nearly  the  same  time  and  caused  a double  context  switch.  The 
variations  did  not  cause  any  serious  operational  anomalies  in  the 
application  in  the  selected  flight  control  configuration  or  the  engine 
control  configuration.  However,  it  did  make  the  difference  between  meeting 
deadlines  and  failing  in  one  of  the  marginally  overloaded  flight  control 
configurations.  This  points  out  the  need  to  thoroughly  evaluate  the 
interaction  of  the  stochastically  varying  workload  and  the  specific 
scheduler  rules  in  all  unusual  system  operating  situations  (failure 
recovery,  temporary  overload  etc.)  to  ensure  no  unexpected  side  effects. 

The  results  presented  in  this  report  present  an  optimistic  picture  of  the 
candidate  architecture  performance.  The  system  was  assumed  to  operate  near 
certain  hardware  limits.  When  more  realistic  values  for  the  system 
overhead  functions  are  available  from  proof-of-concept  testing,  the 
performance  measures  will  probably  suffer.  Furthermore,  some  key 
performance  interactions  were  not  modeled  in  the  performance  simulation. 
These  include  ic  network  operation  and  the  operation  of  the  shared  bus  in 
each  FTP  channel. 

The  application  sends  time-critical  data  across  the  IC  network.  One 
concern  is  the  ability  of  the  IC  network  to  meet  the  time-critical  end-to- 
end  data  transfer  requirements  of  the  application  during  normal  operation. 
Since  the  IC  network  operates  with  unsolicited  messages,  the  network  must 
be  periodically  polled  to  determine  whether  any  communication  has  been 
received.  This  IC  communications  process  executes  on  the  IOP,  which  is 
also  responsible  for  the  application  I/O  operation.  Therefore,  another 
concern  is  the  effect  of  IC  network  communications  on  the  application  I/O 
activity. 

For  the  application  to  complete  its  I/O  activity  and  IC  activity,  it  must 
transfer  data  from  the  cp  to  the  IOP  through  a shared  bus.  The  shared  bus 
has  two  states,  locked  and  unlocked.  Vhen  the  shared  bus  is  locked,  access 
to  other  users  is  blocked.  A major  concern  is  whether  a lack  of 
coordination  between  the  system  processes  in  the  CP  and  IOP  can  lead  to 
shared  bus  utilization  problems.  This  is  a potential  cause  of  serious 
degradation  in  the  application  performance. 


224 


5.0 


REFINED  ARCHITECTURE  DESIGN 


The  candidate  system  evaluation  effort  described  in  section  3 for 
reliability  and  in  section  4 for  performance  demonstrated  that  the 
candidate  was  not  capable  of  meeting  the  system  requirements.  The 
predicted  safety  and  mission  reliability  values  exceeded  the  system 
constraints.  Furthermore,  the  predicted  timing  needs  of  the  major  control 
functions  did  not  leave  adequate  growth  capability.  The  flight  control 
group  workload  strained  the  system  capacity  in  both  computing  and  I/O 
activity.  As  a result,  the  IAPSA  II  candidate  system  concept  was  refined 
to  improve  its  performance  and  reliability. 

Three  approaches  were  taken  to  refine  the  candidate  architecture  to  better 
match  the  system  needs.  The  first  approach  was  to  balance  the  computing 
and  I/O  workload  between  the  engine  and  flight  control  groups.  The 
preliminary  timing  estimates  showed  that  the  flight  control  group  was 
heavily  loaded,  whereas  the  opposite  was  true  for  the  engine  control  group. 
Shifting  the  system  workload  from  the  flight  control  group  to  the  engine 
control  groups  should  reduce  the  growth  constraint  problem. 

The  second  approach  was  to  improve  the  system  failure  protection.  The 
reliability  results  for  the  candidate  architecture  show  that  the  dominant 
safety  failure  sequences  such  as  temporary  exhaustion  of  body  motion 
sensors  involved  two  failures.  A goal  for  the  refined  configuration,  then, 
is  to  maintain  flight  safety  with  all  two  failure  sequences.  In  the 
mission  reliability  area,  the  candidate  architecture  suffered  from  too  many 
single  failure  situations.  Again,  the  goal  for  the  refined  system  is  to 
maintain  full  mission  capability  with  all  single  failures.  Steps  taken  to 
achieve  these  goals  will  be  discussed  later  in  this  section. 


The  final  approach  for  refining  the  architecture  was  to  reduce  the  number 
of  communication  elements  in  the  system.  Large  networks  have  several 
disadvantages  when  compared  to  small  networks.  The  preliminary  DENET 
simulation  experiments  showed  how  the  size  of  the  individual  networks 
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dramatically  affected  the  time  needed  to  regrow  a network.  Another 
negative  characteristic  of  large  networks  is  that  the  probability  of 
network  repair  action  increases  with  the  number  of  elements.  Finally,  from 
a performance  standpoint,  when  a fixed  number  of  sensors  and  actuators  are 
spread  across  fewer  interface  devices,  the  number  of  transactions  needed  to 
access  them  is  reduced.  Because  the  transaction  overhead  time  is  a big 
contributor  to  I/O  activity  duration,  reducing  the  number  will  decrease  the 
I/O  workload.  In  summary,  reducing  the  number  of  communication  elements 
should  improve  both  the  performance  and  reliability  aspects  of  the  system 
concept. 

The  resulting  refined  configuration  is  shown  in  figure  5.0-1.  The  most 
significant  change  is  the  organization  of  system  components  into  two  major 
groups  instead  of  three.  This  configuration  is  physically  similar  to  one 
of  the  options  considered  for  the  candidate  architecture  in  reference  1. 
The  two  engine  control  groups  of  the  candidate  architecture  are  collapsed 
into  one.  Functions  are  reallocated  to  better  balance  the  system.  Details 
of  these  and  other  changes  are  presented  in  sections  5.1,  5.2,  and  5.3.  A 
reliability  evaluation  of  this  architectural  concept  is  discussed  in 
section  5.4,  and  some  timing  estimates  are  made  in  section  5.5. 

5.1  Function  Allocation  Changes 

The  application  computing  functions  were  reallocated  because  the 
performance  analysis  showed  that  the  flight  control  site  was  overloaded 
while  the  engine  control  sites  were  underused.  This  meant  splitting  the 
functions  included  in  the  flight  control  group  in  a way  that  did  not  cause 
communication  bottlenecks  on  the  system  networks.  Another  consideration 
was  the  redundancy  level  match  between  the  computing  sites.  In  a system 
without  function  migration,  critical  functions  that  must  tolerate  two 
failures  to  meet  reliability  requirements  must  execute  on  quadruple 
redundant  sites.  Therefore,  in  order  to  move  any  critical  functions,  the 
destination  site  must  be  quadruple  redundant. 
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Figure  5.0-1.  Refined  Configuration  Overview 


Consideration  must  also  be  given  to  the  awkwardness  of  adapting  the 
candidate  architecture  configuration  to  a single-engine  aircraft.  With  one 
engine,  one  site  is  responsible  for  flight-critical  thrust  control.  Loss 
of  that  site  is  safety  critical.  Therefore,  the  engine  control  site  must 
be  quadruple  redundant. 

Rather  than  change  the  redundancy  level  of  one  of  the  two  engine  control 
sites,  the  refined  configuration  has  two  quadruple- redundant  computing 
sites.  This  means  that  each  site  is  suitable  for  safety-critical  functions 
and  that  the  function  reallocation  process  can  be  relatively  unconstrained. 
Furthermore,  this  new  configuration  will  be  more  adaptable  to  a single 
engine  vehicle. 

The  first  step  in  changing  the  computing  allocation  was  to  combine  the 
control  for  both  propulsion  systems  in  site  B (fig.  5.0-1).  The 
preliminary  timing  estimates  indicated  that  this  computing  load  could  be 
easily  handled  by  one  site.  Next  the  high-workload  trajectory-following 
function  was  allocated  to  site  B.  This  offloaded  the  application  computing 
in  site  A.  Since  it  has  a relatively  slow  update  rate,  the  relative  time 
delay  associated  with  any  data  transfer  over  the  IC  network  is  smaller  than 
for  the  other  flight  control  functions.  Finally,  the  air  data  functions 
were  moved  to  site  B.  The  inlet  control  function  has  always  required  the 
highest  update  rates  for  air  data;  the  associated  move  of  the  air  data 
sensors  to  group  B also  helped  to  reduce  the  congestion  on  the  group  A I/O 
network.  The  disadvantage  of  the  move  was  that  it  introduced  some 
additional  time  delay  in  the  air  data  for  the  manual  control  function.  As 
a result  of  these  changes,  the  refined  system  has  more  evenly  loaded  sites. 

The  configuration  and  functionality  of  the  candidate  propulsion  system  were 
reevaluated  during  the  refined  configuration  effort.  Some  changes  were 
made  as  a result  of  this  study.  The  changes  ranged  from  device 
nomenclature  adjustments  to  revised  ground  rules  for  the  mission  capability 
and  safety  effects  of  propulsion  subsystem  failure  conditions.  The 
following  subsection  provides  a brief  overview  of  the  differences  in  the 
refined  propulsion  system. 
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The  nomenclature  changes  for  the  refined  configuration  reflect  some 
mechanization  changes  assumed  for  the  propulsion  control  functions.  These 
changes  for  the  most  part  had  only  a minor  effect  on  the  system 
configuration.  The  more  significant  changes  were  in  the  analysis  of  failure 
effects  on  the  operational  performance  of  the  aircraft. 

In  the  inlet,  a forward  ramp  actuator,  an  aft  ramp  actuator,  and  an  inlet 
bypass  door  are  controlled  instead  of  the  upper  ramp,  lower  ramp,  and 
bypass  ring  assumed  in  the  candidate  system.  The  inlet  sensors  provide 
roughly  the  same  measurements  as  in  the  candidate  system  except  that  the 
terminology  now  refers  to  forward  ramp  No.  3 static  pressure  sensor  instead 
of  duct  static  pressure  sensor.  The  functionality  changes  for  these 
sensors  are  reflected  in  the  failure  analysis  results,  which  is  summarized 

later. 

A different  actuation  concept  assumed  for  the  nozzle  devices  leads  to  new 
nomenclature.  The  device  that  controls  engine  exit  area  is  now  called  the 
nozzle  area  actuator  instead  of  the  converging  nozzle  actuator.  The 
remaining  two  actuators  now  control  thrust  reversing  and  thrust  vectoring 
separately  instead  of  jointly.  The  new  devices  are  the  thrust  reversing 
vane  and  thrust  vectoring  flap  actuators,  replacing  the  upper  and  lower 
nozzle  actuators. 

In  the  candidate  system,  the  fuel  flow  meter  was  used  along  with  fuel 
metering  valve  position  in  a fuel  flow  model.  This  model  was  assumed  to 
allow  perfect  identification  of  all  first  failures  and  perfect  detection  of 
all  second  failures.  The  flow  meter  was  not  used  in  the  refined 
configuration  propulsion  control  concept. 

The  afterburner  fuel  control  mechanization  was  changed  for  the  refined 
configuration.  The  candidate  system  concept  had  a single  flow  metering 
valve  that  controlled  fuel  flow  to  five  zones  through  zone  flow  control 
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valves.  The  refined  configuration  had  two  metering  valves,  the  afterburner 
core  and  duct  metering  valves  controlling  flow  to  the  five  afterburner  fuel 
nozzles.  Flow  to  the  different  zones  was  turned  on  and  off  in  order  by 
action  of  an  afterburner  segment  sequence  actuator. 


5.2  Data  Distribution 

There  are  many  possible  alternatives  to  the  candidate  architecture  data 
distribution  approach.  These  alternatives  range  from  minor  changes  in  the 
candidate  to  entirely  different  concepts.  Only  two  data  distribution 
options  were  looked  at  in  detail  during  the  refinement  effort.  One  of 
these  incorporated  a minimum  change  to  the  candidate  data  distribution 
concept,  and  the  other  replaced  the  mesh  netvork  with  a set  of  buses.  Even 
in  the  bus  option  the  data  distribution  interface  changes  were  minor.  The 
candidate  system  data  distribution  problems  will  be  discussed  before  these 
options  are  presented. 

The  first  problem  is  that  the  I/O  system  growth  capability  for  the  flight 
control  group  is  inadequate.  The  simplified  estimates  generated  before  the 
simulation  experiments  showed  that  the  flight  control  group  was  slightly 
overloaded,  while  the  engine  groups  easily  satisfied  the  growth  capability 
requirement.  The  more  detailed  estimates  provided  by  the  simulation 
experiments  showed  that  the  actual  growth  capability  was  much  worse. 

A timeline  of  the  flight  control  I/O  activity  showed  that  there  were  three 
major  time  users.  The  biggest  time  requirement  was  due  to  the  need  to  run 
the  input  and  much  of  the  output  data  through  the  data  exchange  hardware. 
The  performance  estimate  assumed  that  data  would  be  put  through  the  data 
exchange  at  the  hardware  speed  limit.  (Our  performance  modeling  assumes 
that  the  respective  system  software  is  extremely  efficient.)  Successful 
data  exchange  operation  is  tied  intimately  to  fault-tolerant  clock 
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operation.  It  is  also  used  to  indicate  whether  the  redundant  channels  are 
in  instruction  synchronism.  For  these  and  other  reasons  there  are  physical 
and  conceptual  limits  to  increasing  speed  in  this  area  with  the  current  FTP 
operating  principles. 

Bus  activity  and  DIU  turnaround  time  were  the  next  largest  time  users  for 
I/O  activity.  Bus  activity  refers  to  the  time  spent  transmitting  data  on 
the  bus,  and  DIU  turnaround  refers  to  the  time  used  by  the  DIU  to  interpret 
incoming  bus  messages,  take  appropriate  action,  and  begin  the  bus  response 
message.  Here  again  there  are  limits  to  the  improvements  possible.  Bus 
speed  could  be  increased  easily  by  going  to  more  advanced  techniques,  but  a 
new  node  hardware  concept  may  be  required  if  virtual  bus  operation  is  to  be 
maintained.  Similarly,  faster  DIU  response  time  requires  either  more 
powerful  DIU  hardware  or  a different  system  operational  concept.  Current 
operating  assumptions  are  that  all  device  activity  (reading  sensors  or 
commanding  actuators)  takes  place  in  response  to  command  messages  over  the 
network  from  the  FTP. 

The  time  spent  waiting  to  begin  postprocessing  in  the  IOP  after  the  IOS  has 
executed  the  chain  of  transactions  is  also  a potentially  large  user  of 
time.  Since  the  chain  execution  occurs  without  IOP  involvement,  the 
mechanism  it  uses  to  detect  when  activity  is  completed  can  be  important. 
The  simplified  timing  estimate  assumed  that  this  time  was  zero,  but  a 
fairly  coarse  polling  policy  was  modeled  in  the  DENET  simulation 
experiments,  which  showed  this  area  to  be  a potential  problem. 

The  I/O  activity  overload  problem  was  addressed  by  reducing  the  number  of 
transactions  on  the  flight  control  network.  The  first  step,  moving  the  air 
data  sensors  off  the  flight  control  network,  has  already  been  mentioned. 
The  next  step,  consolidating  the  system  DIUs,  will  have  several  beneficial 
effects.  From  a performance  standpoint,  fewer  DIUs  means  that  fewer 
transactions  are  needed  to  communicate  with  the  system  sensors  and 
actuators.  The  remaining  DIUs  are  connected  to  more  devices.  The  amount 
of  data  transferred  that  is  directly  associated  with  the  devices  is  not 
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changed.  However,  the  data  associated  with  each  transaction  (transaction 
overhead)  is  reduced.  Since  this  transaction  overhead  data  must  go  through 
the  data  exchange  and  be  transmitted  over  the  bus,  a reduction  helps  in  two 
of  the  big  time-user  categories. 

There  are  reasons  other  than  performance  for  reducing  the  number  of 
communication  elements  in  the  system.  One  disadvantage  of  large  networks 
is  that  there  are  more  elements  to  fail.  A system  with  many  elements  will 
have  to  undergo  repair  much  more  often  than  a system  with  only  a few 
elements.  Another  disadvantage  pointed  out  by  the  DENET  simulation 
experiments  is  that  larger  networks  have  exponentially  longer  regrow  repair 
times  than  smaller  networks.  The  sheer  size  of  the  larger  network  can  add 
to  repair  computation  complexity  and  time.  For  these  reasons,  reducing 
network  size  provides  a benefit  in  reducing  both  repair  frequency  and 
repair  duration. 

The  candidate  architecture  uses  two  I/O  networks  per  group,  with  the 
redundant  elements  divided  between  them.  Having  two  networks  allows  the 
application  to  continue  operating  while  one  of  the  networks  is  being 
repaired.  An  interesting  observation  is  that  as  the  number  of  I/O  networks 
increases  the  compelling  need  for  reconfiguration  decreases. 

If  all  the  system  devices  are  located  on  a single  network,  communications 
must  be  reestablished  very  rapidly  after  network  failures  with  at  least  a 
critical  set  of  the  devices.  The  time  allowed  to  restore  communication  to 
this  critical  subset  is  limited  by  how  long  the  application  can  be  safely 
interrupted.  For  these  types  of  systems,  the  network  reconfiguration 
action  naturally  takes  priority  over  the  application  computing.  If  the 
network  repair  can't  be  accomplished  in  the  allowable  safe  interruption 
time,  then  a single  network  is  unacceptable.  In  this  situation  a single 
failure  can  cause  loss  of  safety. 

A system  with  two  networks  is  different  in  that  a critical  subset  of 
devices  is  unaffected  by  the  network  loss,  and  therefore  the  repair  time 
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deadline  is  much  less  constrained.  In  the  candidate  system  the  constraint 
is  set  by  the  likelihood  of  nearly  coincident  faults  that  jeopardise 
safety.  The  repair  action  and  continued  application  computing  priority 

situation  is  reversed.  Because  netvork  repair  does  not  have  to  be 

completed  to  communicate  with  a critical  subset  of  the  sensors  and 

actuators,  it  must  have  lover  priority  than  the  application  function 
required  for  safe  flight.  It  is  allowable  for  netvork  repair  to  take 

longer  than  the  safe  function  interruption  time.  The  reversal  of  priority 
means  that  the  repair  activity  is  accomplished  in  the  application  idle 
time,  which  causes  its  completion  to  be  delayed. 


As  the  number  of  networks  increases,  further  dividing  the  redundant  system 
devices,  there  is  eventually  no  need  for  inflight  repair.  The  aircraft  can 
suffer  the  loss  of  an  entire  set  of  redundant  devices  and  still  meet  system 
reliability  requirements.  For  this  reason  only  two  options  for  data 
distribution  were  considered  in  the  refined  configuration  study.  These  two 
options  are  shown  in  figure  5.2-1.  The  natural  redundancy  in  the  system 
tends  to  separate  the  sensors  and  actuators  into  four  groups.  Reliability 
concerns  will  keep  redundant  electronics  elements  in  separate  enclosures. 
Figure  5.2-1  shows  how  two  sets  of  quadruple-redundant  enclosures  would  be 
connected  with  the  mesh  network  and  the  linear  bus  data  distribution 
alternatives.  The  assignment  of  devices  to  enclosures  is  presented  in 
tables  5.2-1  and  5.2-2.  In  the  mesh  network  the  devices  are  connected  via 
two  networks,  whereas  in  the  bus  option  they  are  connected  by  four  linear 
buses.  The  key  difference  is  that  the  mesh  network  has  spare  elements  to 
allow  reconfiguration,  whereas  the  bus  does  not.  These  two  options  are 
discussed  in  more  detail  in  the  following  sections. 


5.2.1  I/O  Network  Option 

The  mesh  network  data  distribution  option  is  very  similar  to  the  candidate 
architecture.  The  key  changes  are  the  consolidation  of  netvork  nodes  and 
DIUS  and  the  reallocation  of  system  devices.  There  are  still  two  networks 
per  major  group.  Figure  5. 2. 1-1  shows  the  layout  of  one  of  the  group  A I/O 
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Figure  5.2- 1.  Mesh  Network  and  Linear  Bus  Options 
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Table  5.2-1.  Sensor/Actuator  Computer  Connection— Group  A 


Node/DIU  assignments 

Device 

Forward 

Mid 

Right  wing 

Left  wing 

Tail 

DBBD! 

DBODI 

naiiDi 

BBBBI 

DBBDI 

Body  accelerometers 

2 2 2 2 

Body  gyros 

2 2 2 2 

Pitch  stick 

1111 

Roll  stick 

1111 

Rudder  pedal 

1111 

Flap  lever 

1 1 1 

Pitch  trim 

i i i 

Roll  trim 

i i i 

Yaw  trim 

1 1 1 

Left  canard 

1 1 

Right  canard 

1 1 

Nosewheei 

1 1 

Leading  edge 

1 1 

L outboard  flaperon 

1 1 

R outboard  flaperon 

i i 

L inboard  flaperon 

l I 

R inboard  flaperon 

i i 

LTE  flap 

1 1 

R TE  flap 

i i 

4 1 

L rudder 

1 1 

R rudder 

1 1 

L outboard  wing  accel 

1 1 1 

R outboard  wing  accel 

i i i 

L midwing  accel 

1 1 1 

R midwing  accel 

i i i 

L inboard  wing  accel 

1 1 1 

R inboard  wing  accel 

i i i 

FTP  channels 

1111 

(group  A) 

235 


Table  5.2-2.  Sensor/Actuator  Computer  Connection— Group  B 


Device 

Noda/DIU  assignments 

Air 

Inlet 

Engine 

Nozzle 

DBBD 

niiiiiigrg 

mraiqra 

IWETIIUI53 

Angle  of  attack 

1111 

Angle  of  sideslip 

1111 

Static  pressure 

1111 

Total  pressure 

1111 

Total  temperature 

i i 

Left  throttle 

1 1 

Right  throttle 

1 1 

Forward  ramp 

1111 

Aft  ramp 

1111 

Inlet  bypass  door 

1111 

Forward  ramp  3 static  pressure 

1111 

Normal  shock  total  pressure 

1111 

Normal  shock  static  pressure 

1111 

Nozzle  area 

1111 

Thrust  reversing  vane 

1111 

Thrust  vectoring  flap 

1111 

Fan  face  static  pressure 

1111 

Fan  face  temperature 

1111 

Fan  speed 

1111 

Compressor  speed 

1111 

Burner  pressure 

1111 

Fan  turbine  inlet  temperature 

1111 

Afterburner  pressure 

1111 

Fan  guide  vane 

1111 

Compressor  vane 

1111 

Fuel  metering  valve 

1111 

Afterburner  core  metering  valve 

1111 

Afterburner  duct  metering  valve 

1111 

Afterburner  segment  sequencer 

1111 

Afterburner  light  off  detector 

Main  fuel  shutoff 

UBBI 
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networks.  Group  A has  two  networks  of  10  nodes  and  DIUs  each.  This  is  a 
reduction  of  eight  nodes  and  six  DIUs  compared  to  the  flight  control 
network  of  the  candidate  architecture.  The  resulting  allocation  of  devices 
to  DIUs  is  shown  in  the  reliability  model  section.  There  is  one  DIU  per 
network  node  in  the  group  A networks.  There  are  no  dedicated  root  nodes  in 
this  option;  root  links  are  connected  to  nodes  that  service  DIUs. 

The  group  B I/O  network  layout  is  shown  in  figure  5. 2. 1-2.  Group  B also 
has  two  networks,  each  containing  eight  nodes  and  DIUs.  Each  group  B 
network  is  connected  to  elements  on  both  engines.  There  is  no  reduction  in 
the  total  number  of  nodes  and  DIUs  compared  to  the  candidate  architecture, 
although  they  are  now  consolidated  into  two  networks.  Devices  are 
allocated  differently  than  the  candidate  architecture.  The  air  data 
sensors  and  the  throttle  command  sensors  have  been  moved  from  the  flight 
control  networks  to  group  B.  Like  group  A,  group  B has  no  dedicated  root 
nodes . 

The  number  of  transactions  sent  over  the  group  A networks  has  been  reduced 
due  to  the  consolidation  of  DIUs.  For  comparison,  the  new  100  Hz  rate 
group  has  six  transactions  per  network  versus  the  eight  transactions  of  the 
candidate  architecture.  There  are  six  50  Hz  transactions  in  the  refined 
design  compared  to  10  in  the  candidate  architecture.  The  25  Hz 
transactions  have  been  eliminated.  However,  the  reallocation  of  devices 
and  the  placement  of  both  engines  on  the  same  networks  increases  the  number 
of  transactions  on  the  group  B networks.  Group  B now  has  four  100  Hz 
transactions,  two  50  Hz  transactions  and  four  25  Hz  transactions.  In  the 
candidate  architecture  each  engine  control  rate  group  had  a single 
transaction.  Thus  the  relatively  overloaded  flight  control  networks  have 
had  a traffic  reduction,  while  the  use  of  the  lightly  loaded  engine 
networks  has  increased.  A performance  assessment  of  these  changes  is 
discussed  in  section  5.5. 

One  change  in  the  network  configuration  is  due  to  the  dominant  reliability 
problem  found  in  the  candidate  architecture.  Recall  that  the  layout  of  the 
candidate  architecture  had  each  device  connected  to  only  one  DIU  and  one 
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node.  The  reliability  evaluation  shoved  that  this  simple  "brickvalled" 
scheme  easily  satisfied  system  requirements,  with  the  exception  of  the  body 
motion  sensors.  In  the  refined  I/O  network  option,  the  critical  body  motion 
sensors  are  connected  to  both  group  A networks  via  dual-port  OIUs.  This  is 
shown  in  figure  5. 2. 1-3.  The  purpose  of  this  is  to  ensure  that  two 
failures  are  required  before  the  system  is  vulnerable  to  temporary 
exhaustion  failures.  A critical  design  requirement  generated  by  the 
cross-connection  approach  in  the  refined  configuration  is  to  ensure  that  no 
single  failure  in  the  dual-port  DIU  can  cause  simultaneous  repair 
activities  on  both  networks.  Note  that  the  cross  connection  is  only  used 
for  the  MID  DIUs,  where  the  reliability  analysis  showed  it  was  required. 

There  are  several  system  operation  alternatives  for  this  cross-connected 
configuration.  The  first  alternative  is  to  use  the  cross-network  links 
always,  transmitting  the  device  data  over  both  networks  during  normal 
operation.  This  is  advantageous  because  it  doesn't  require  any  special 
operating  modes  to  avoid  temporary  exhaustion  vulnerability,  but  it  causes 
additional  transactions  on  networks  that  are  already  heavily  loaded. 

There  are  two  operational  alternatives  if  the  cross-network  links  are  used 
only  when  reacting  to  a fault.  One  alternative  requires  a fast  reaction  to 
a fault,  while  the  other  alternative  can  tolerate  a much  slower  fault 
reaction. 

The  fast  reaction  alternative  would  take  no  action  until  temporary 
exhaustion  is  imminent.  For  example,  a DIU  or  node  fails  followed  by  a 
failure,  causing  repair  on  the  other  network.  In  the  fast  reaction 
alternative  no  action  is  taken  until  the  second  failure.  The  situation 
must  be  recognized  by  the  application  and  action  taken  to  use  the 
cross-connection  link  before  a critical  time  period  elapses.  Ths  need  for 
special  action  must  be  discerned  from  the  error  information  provided  by  the 
I/O  system  services.  The  special  action  would  consist  of  (1)  selecting 
transactions  in  the  existing  I/O  request  that  are  normally  off  to 
communicate  with  the  devices  over  the  cross-network  links,  (2)  using  an 
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Dual  port  DIU 


Nodes 


Figure  5.2. 1-3.  Body  Motion  Sensor  Cross  Connection 
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alternative  I/O  request  for  the  remaining  good  network  that  contains  the 
additional  transactions  for  cross-network  link  communication,  or  (3)  making 
an  additional,  emergency  I/O  request  containing  only  the  special 
transactions  every  compute  cycle  for  the  duration  of  the  network  repair. 
Each  of  these  special  action  alternatives  has  certain  drawbacks  with  the 
current  version  of  I/O  system  services.  It  seems  prudent,  therefore,  to 
plan  an  alternative  with  a non-time-critical  fault  reaction. 

A slow  fault  reaction  strategy  only  requires  the  application  to  recognize 
when  the  system  is  vulnerable  to  a subsequent  failure  causing  temporary 
exhaustion.  This  means  that  the  cross-connection  links  would  be  used  after 
the  first  applicable  failure  instead  of  the  second.  In  this  case  the 
action  taken  by  the  application  is  not  time  critical.  The  vulnerable 
situation  is  conveniently  indicated  when  data  from  only  two  sensors  are 
being  sent  on  one  of  the  networks  due  to  previous  failures.  Vhen  the 
application  detects  this  vulnerability  it  can  change  the  I/O  traffic 
loading  via  transaction  selection  to  ensure  that  a subsequent  network 
repair  will  not  cause  temporary  exhaustion.  Although  this  action  seems 
straightforward,  the  application  must  react  to  a large  number  of  possible 
situations  (some  of  which  cannot  be  corrected).  This  solution  does  require 
a substantial  new  application  redundancy  management  process. 

5.2.2  Redundant  Bus  Option 

An  alternative  data  transfer  system  outlined  earlier  consists  of  four  non- 
reconf igurable  linear  buses.  The  number  and  arrangement  of  enclosures, 
DIUs,  and  devices  is  unchanged.  All  of  the  redundant  devices  are  divided 
evenly  across  the  four  buses.  Since  the  bus  is  not  reconf igurable  there 
are  no  network  nodes  in  the  system.  Communication  over  the  bus  system  is 
carried  out  just  at  it  is  over  the  mesh  network.  Recall  that  the  mesh 
network  operates  like  a virtual  bus,  with  each  device  receiving  all  bus 
activity  at  approximately  the  same  time.  The  same  command/response 
protocol  is  assumed  for  the  bus  option.  The  data  distribution  interface 
and  the  10  system  services  are  therefore  assumed  to  be  identical  in  this 
comparison. 
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The  bus  option  illustrates  the  limiting  case  in  which  the  number  of 
networks  in  a system  is  increased  to  the  point  that  reconfiguration  after 
communication  faults  is  not  necessary.  A major  benefit  of  this  step  is  the 
elimination  of  the  complex  I/O  redundancy  management  software.  Typically, 
validation  of  large,  complex  software  processes  is  difficult  and  costly. 
Although  this  is  a problem  for  the  building  block  system  provider  to  solve, 
the  application  designer  must  have  confidence  that  validation  is 
achieveable  by  the  time  the  system  is  scheduled  for  first  flight.  Because 
the  bus  option  does  not  include  any  of  the  network  reconfiguration 
functionality,  it  sidesteps  any  associated  validation  issue. 

To  allow  a more  straightforward  comparison  between  the  mesh  network  and  bus 
options,  some  configuration  aspects  were  kept  constant  in  both.  Only  four 
connections  to  the  I/O  devices  were  used  in  both  options.  This  means  that 
in  the  bus  option  each  bus  is  singly  connected  to  an  FTP  channel,  whereas 
the  mesh  network  option  uses  only  one  root  link  per  FTP  channel.  Neither 
of  these  may  be  acceptable  as  a final  configuration  choice,  but  it  keeps 
the  comparison  on  more  even  terms.  One  implication  of  the  bus  option  is 
that  an  active  DIU  failure  can  lead  to  the  permanent  loss  of  the  entire  bus 
and  all  connected  devices.  The  normal  I/O  network  recovery  action  will 
disable  the  DIU  link  and  restore  communications  in  such  a situation  on  the 
mesh  network.  Special  design  precautions  could  be  taken  to  make  an  active 
DIU  failure  unlikely  for  the  bus  option.  Because  this  would  result  in  an 
unsymmetric  comparison,  the  same  DIU  design  will  be  assumed  for  both 
options. 

5.2.3  Electric  Power  Distribution 

The  candidate  architecture  analysis  did  not  consider  the  details  of  the 
electrical  power  distribution.  In  the  refined  system  study  more  attention 
was  paid  to  the  implications  of  the  power  distribution  connection.  The 
Fault  Tolerant  Electric  Power  (FTEP)  system  study  configuration  (reference 
3)  was  used  as  a baseline  for  IAPSA  II.  In  that  study  four  distributed 
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load  centers  (ELMC)  provided  electric  power  to  the  critical  users.  Main 
aircraft  power  buses  were  connected  to  the  ELMCs,  which  monitored  the 
airplane  source  and  switch  when  necessary.  Each  load  center  had  an 
uninterruptible  battery  bus  for  dc  users  that  was  tied  to  one  of  two 
aircraft  batteries. 

The  simplest  connection  alternative  for  a system  that  is  primarily 
quadruple  redundant  would  have  one  ELMC  source  per  enclosure.  This 
alternative  was  broadly  evaluated  with  satisfactory  results  in  the 
candidate  architecture  reliability  study.  Each  enclosure  has  a single 
local  power  supply  that  satisfies  the  bulk  of  all  enclosure  needs.  With 
this  single  connection  organization  care  must  be  taken  when  assigning 
electrical  connections.  All  elements  that  have  a dependency  relationship 
(devices,  DIUs,  buses,  FTP  channels)  must  be  connected  to  the  same  ELMC 
source.  This  guarantees  that  when  a single  source  is  lost  only  one  level 
of  redundancy  for  any  device  is  affected.  Otherwise,  loss  of  a single 
source  could  bring  down  more  than  one  redundant  device  via  a dependency 
relationship.  For  example,  a source  could  affect  a DIU  (and  all  attached 
devices)  on  one  bus  and  a device  of  the  same  type  on  another  bus. 

The  single  power  source  alternative  presents  some  special  concerns  for  the 
mesh  network  option  that  were  not  evaluated  in  the  candidate  architecture 
analysis.  When  one  power  source  fails,  one  fourth  of  the  nodes  fail.  As  a 
consequence,  power  source  loss  is  another  cause  of  network  repair  action  in 
a singly  connected  system.  The  most  general  fix  is  regrowth  of  the 
network.  In  a two-network  system,  regrow  must  be  restricted  to  a single 
network  so  that  the  application  can  continue  operation  with  devices 
connected  via  the  other  network.  Additionally,  the  power  connection  layout 
must  ensure  that  the  half  of  the  network  remaining  after  a power  source 
loss  is  a viable  configuration,  with  no  isolated  nodes. 

Rather  than  accepting  single  power  source  losses  as  a cause  of  temporary 
I/O  network  failures,  the  refined  design  incorporated  a dual  power 
connection  scheme.  As  a minimum,  this  delays  any  I/O  network  effect  until 
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the  second  electrical  failure.  The  specific  configuration  is  shown  in 
figure  5. 2. 3-1.  Two  of  the  four  power  sources  service  all  of  the  elements 
on  a specific  network.  Each  network  node  is  connected  to  both  of  the 
network  power  sources.  When  both  network  power  sources  fail,  it  is 
unimportant  that  the  nodes  are  lost  since  all  serviced  devices  on  that 
network  are  also  lost.  With  this  configuration,  power  source  losses  are 
irrelevant  to  I/O  network  operation. 

Another  power  connection  concern  is  surface  control.  A hard  requirement  is 
that  no  two  failures  can  cause  degraded  capability  on  more  than  one  control 
axis.  Otherwise  this  would  be  a dominant  loss-of-safety  situation  for  the 
refined  configuration.  For  single  power  connection  configurations  this 
means  that  no  two  ELMC  failures  can  be  allowed  to  cause  passive  surfaces  on 
more  than  one  axis.  In  the  baseline  power  configuration,  each  surface  is 
driven  by  two  channels,  each  of  which  is  powered  by  a single  source.  If 
symmetrical  flaperon  pairs  are  connected  identically,  six  surface  types 
must  tolerate  both  failure  situations  with  only  one  surface-type  failure. 
These  are  the  right  canard,  right  rudder,  inboard  flaperons,  outboard 
flaperons,  left  canard  and  left  rudder.  Because  there  are  six  possible 
combinations  of  the  four  power  sources  taken  two  at  a time,  this  seems 

feasible. 

For  the  bus  option  the  surface  connection  constraint  can  be  met  with  no 
problems.  However,  in  the  mesh  network  option,  the  surface  control 
constraint  conflicts  with  the  node  power  concept  developed  earlier.  The 
node  power  concept  basically  means  that  all  devices  on  one  network  are 
powered  by  the  same  two  sources.  Without  a special  fix,  satisfying  both 
constraints  would  mean  that  both  actuation  channels  on  some  surfaces  would 
be  signaled  over  the  same  network.  Thus,  during  temporary  network  outages 
for  repair,  that  surface  would  switch  to  a passive  operating  mode.  This 
would  violate  the  network  connection  ground  rule  established  during  the 
candidate  architecture  layout.  The  solution  used  in  the  refined 
configuration  is  shown  in  figure  5. 2.3-2.  Instead  of  the  single  power 
source  connection,  the  MID  DIU  is  connected  to  two  power  sources. 
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Figure  5.2. 3- 1 . Refined  Configuration — Node  Power 
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Figure  5.2. 3-2.  Surface  Actuation  Power  Connection 
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Thus  in  the  mesh  network  option  there  are  several  exceptional 
characteristics  about  the  MID  DIU  and  its  devices.  Its  network  cross 
connection  and  dual  power  sources  are  unique.  This  makes  comparison  with 
the  bus  option  somewhat  awkward.  However,  this  comparison  would  be  much 
more  difficult  if  cross  connection  and  dual  power  sources  were  used  for  all 
enclosures  in  the  mesh  network  option. 

5.3  Actuation  Changes 

One  area  of  concern  in  the  candidate  architecture  reliability  study  was 
surface  actuation.  The  problems  included  two  failure  situations  resulting 
in  a loss  of  safety  and  single  failure  cases  that  caused  loss  of  mission 
capability.  Two  major  contributors  were  undetected  actuation  channel 
failures  and  active  DIU  failures. 

The  first  contributor,  undetected  channel  faults,  was  addressed  by 
increasing  the  redundancy  of  the  actuator  processor  and  associated  position 
sensor.  The  operating  concept  was  changed  to  require  two-processor 
agreement  to  drive  the  surface.  The  actuator  channel  now  relies  on 
comparison  for  failure  detection  rather  than  the  self-test  hardware  and 
software.  When  the  processors  disagree,  the  channel  must  fail  passive. 
This  additional  redundancy  leads  to  fail-operational/fail-off  capability 
for  each  surface. 

Several  candidate  configurations  were  examined  to  define  the 
interconnection  of  the  actuator  channels  to  the  I/O  network.  Concepts 
where  the  actuation  was  invulnerable  to  temporary  exhaustion  and  did  not 
require  dedicated  cross  actuator  channel  data  paths  were  favored.  The 
straightforward  scheme  used  in  the  refined  configuration  requires  that  the 
concept  be  protected  from  active  DIU  faults. 
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The  second  major  factor,  active  DIU  faults,  was  addressed  by  changing  the 
actuator  communication  concept.  In  the  candidate  architecture,  the  DIU  has 
the  responsibility  for  ensuring  message  integrity  for  its  serviced  devices. 
The  postulated  active  failure  mode  causes  the  DIU  to  continue  meeting  the 
interface  protocol  while  corrupting  the  commands  sent  to  the  actuator.  The 
change  for  the  refined  configuration  is  the  reassignment  of  responsibility 
for  ensuring  message  integrity.  The  actuator  processor  now  verifies  the 
message  that  contains  its  position  command.  This  end-to-end  check 
guarantees  that  a good  actuator  channel  will  not  use  a corrupted  command. 
This  solution  has  the  disadvantage  of  requiring  additional  verification 
processing  in  the  actuator  processor  when  the  actuator  position  command  is 
updated.  In  addition,  the  DIU  must  handle  the  transfer  of  a larger  amount 
of  data  to  each  actuator  interface.  It  must  store  the  entire  command 
message  upon  receipt  and  then  write  it  to  each  actuator.  Therefore  DIU 
processing  requirements  are  also  increased. 

5.4  Reliability  Evaluation 

The  two  data  distribution  options  for  the  refined  configuration,  mesh 
network  and  bus,  were  evaluated  to  verify  that  the  changes  allow  the  system 
to  meet  its  reliability  requirements.  The  reliability  measures  evaluated 
included  safe  flight  and  landing,  full  mission  capability,  and  sustained 
operational  capability.  The  first  two  measures  were  used  in  the 

reliability  evaluation  of  the  candidate  system  described  in  section  4.  The 
new  sustained  operational  capability  measure  is  described  in  the  following 
paragraphs . 

The  sustained  operational  capability  measure  was  used  to  compare  the  two 
options,  emphasizing  their  ability  to  operate  with  failures.  A key  benefit 
of  reconf igurable  systems  is  their  ability  to  restore  operational 
performance  after  failures.  The  major  Air  Force  emphasis  in  reliability 
and  maintainability  is  operational  performance  over  time.  Maintenance 
aspects  are  very  important  in  longer  term  measures,  but  they  are  beyond  the 
scope  of  the  IAPSA  II  study.  Therefore  a measure  was  needed  that  did  not 
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involve  maintenance  activity.  The  selected  measure  vas  based  on  a forward 
base  operating  scenario.  The  scenario  involves  rapid  deployment  to  a 
forward  base  followed  by  immediate  initiation  of  combat  operations  without 
any  integrated  control  system  spares.  The  combat  scenario  envisioned 
relaxed  operating  rules  intended  to  maximize  combat  availability. 
Sustained  operational  capability  is  the  probability  that  an  aircraft  can 
continue  to  fly  combat  missions  without  maintenance  on  any  of  the  control 
system  elements.  Two  conditions  were  assumed  necessary  for  combat  mission 
dispatch.  First,  the  system  must  have  full  mission  capability,  and  second, 
it  must  be  able  to  absorb  one  more  failure  and  continue  to  a safe  landing. 

The  assumed  operating  rules  are  subject  to  discussion.  In  any  case,  this 
is  a somewhat  realistic  measure  of  the  two  systems'  abilities  to  operate 
with  failures.  The  duration  of  this  operational  scenario  is  50  operational 
hours.  This  reflects  about  a week  of  intensive  operations.  The  results  are 
the  probability  that  a specific  aircraft  would  be  unable  to  maintain  combat 
operations  for  the  50-hour  period  because  of  control  system  failures. 

Some  different  reliability  modeling  techniques  were  used  in  the  refined 
system  evaluation.  The  first  technique  was  explicit  truncation  of  the 
models  at  a specified  number  of  failures.  Truncation  greatly  simplifies 
the  reliability  models.  The  technique  is  based  on  the  fact  that  the 
dominant  system  failure  sequences  involve  a small  number  of  element 
failures.  Contributions  to  system  unreliability  from  sequences  with  a 
greater  number  of  failures  are  less  likely  and  therefore  not  significant. 
This  allows  all  system  states  having  a greater  number  of  element  failures 
to  be  modeled  in  an  approximate  manner.  For  our  study,  safety  model 
truncation  at  the  third  failure  level  captured  the  dominant  system  failure 
sequences.  The  mission  and  sustained  capability  models  were  truncated  at 
the  second  failure  level. 

The  baseline  truncation  technique  is  shown  in  figure  5.4-1.  The  technique 
is  based  on  the  CSDL  approach  described  in  reference  4 used  for  the 
Computer  Aided  Markov  Evaluator  (CAME)  program.  The  system  states  are 


250 


categorized  by  how  many  failures  have  occurred  in  the  system  and  whether 
the  system  is  operational  or  failed.  The  number  of  distinct  states  in  each 
category  rises  dramatically  with  failure  level.  In  the  figure  5.4-1 
example,  the  dominant  system  failure  sequences  involve  three  or  fewer 
element  failures. 

Model  construction  is  exact  up  to  the  third  failure  level.  That  is,  all 
state  information  and  all  transition  rates  are  exact  for  all  sequences 
leading  to  the  third  failure  level.  The  first  simplification  step  is  to 
aggregate  all  operational  states  that  have  three  failures  into  a single 
state.  All  the  state  information  is  lost  as  a result  of  this  aggregation. 
Next  a conservative  transition  to  the  next  failure  level  is  built  from  the 
®fl>Ri-®8®ted  operational  state.  This  transition  is  conservative  because  it 
is  larger  than  the  sum  of  the  actual  transition  rates  that  it  replaces. 
The  destination  of  this  conservative  transition  is  the  upper  bound  state, 
which  represents  all  the  system  states  that  have  four  or  more  failures. 

The  upper  bound  state  is  conservatively  treated  as  a system  failure  state 
even  though  it  contains  many  operational  states.  When  evaluated,  the  upper 
bound  state  provides  a conservative  estimate  of  the  error  introduced  by  the 
truncation  technique.  Viewed  another  way,  an  upper  bound  on  the 
probability  of  system  unreliability  is  provided  by  the  sum  of  the 
probability  of  the  system  failure  states  and  the  upper  bound  state.  A 
lower  bound  on  the  system  unreliability  is  provided  by  the  sum  of  the 
system  failure  states  containing  three  or  fewer  failed  elements. 

Further  simplifying  techniques  were  used  that  amounted  to  modification  of 
this  baseline  truncation  technique.  The  justification  for  these  techniques 
is  that  the  relative  likelihood  of  certain  key  system  failure  sequences  is 
important  to  the  evaluation  of  a system's  strengths  and  weaknesses. 
Therefore  it  is  not  usually  necessary  to  know  the  specific  failure 
situation  probability  with  more  than  one  or  two  digit  accuracy.  The 
resulting  simplifying  technique  ignores  some  sequences  that  contribute  to 
the  system's  dominant  failure  situations  when  they  contain  more  than  a 
certain  number  of  failures. 
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For  example,  failure  of  both  hydraulic  systems  causes  loss  of  safety.  A 
large  number  of  three-failure  sequences  involve  failure  of  both  hydraulic 
systems  and  an  unrelated  element.  Taken  together,  the  probability  of  all 
three-failure  sequences  is  much  smaller  than  the  dominant  tvo-failure 
sequence.  Leaving  out  the  three-failure  sequences  introduces  only  a small 
error  in  the  likelihood  of  the  specific  sequence,  and  reduces  the  system 
lower  bound  for  unreliability.  The  benefit  is  a much  smaller  model  in 
terms  of  states  and  transitions. 

Another  simplifying  technique  was  used  with  common  element  failures. 
Common  elements  are  those  that  affect  the  functional  success  of  many  other 
system  elements.  Examples  include  communication  elements,  such  as  nodes 
and  DIUs,  and  power  sources  such  as  hydraulic  systems  or  ELMCs.  From  a 
reliability  modeling  standpoint  the  other  elements  are  dependent  on  the 

common  element.  The  dependency  simplifying  technique  models  only  the  most 
damaging  transitions.  These  are  the  transitions  that  affect  all  the 
dependent  elements.  The  transitions  that  are  left  out  of  the  model  are 

those  that  might  occur  after  a previous  failure  has  affected  one  or  more  of 
the  dependent  elements. 

For  example,  if  a common  element  affects  two  sensors,  A and  B,  the  most 

damaging  transition  will  fail  both  sensors.  If  B has  previously  failed, 
however,  the  subsequent  common  element  failure  will  only  reduce  the 

redundancy  of  the  A elements.  With  the  above  simplifying  techniques,  the 
later  transition  would  not  be  included  in  the  reliability  models.  In  this 
case  the  destination  state  of  the  unmodeled  two-failure  sequence  has  the 
same  capability  as  the  destination  state  of  a much  more  likely 
single-failure  sequence. 

In  all  cases  where  this  dependency  simplifying  technique  was  applied  in  the 
refined  configuration  evaluation,  the  unmodeled  transitions  would  have 
taken  the  system  into  the  aggregated  operational  state.  In  other  words, 
none  of  the  unmodeled  transitions  would  have  appeared  in  any  of  the 
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dominant  system  failure  sequences.  This  technique  greatly  reduces  the 
number  of  transitions  that  must  be  modeled.  However,  the  major  advantage 
is  the  reduced  effort  needed  to  generate  ASSIST  statements  to  cover  all  the 
possible  transitions.  Effort  is  still  required  to  derive  the  correct 
ASSIST  expression  for  the  remaining  transition  as  a function  of  system 
state.  A correct  transition  rate  is  needed  to  ensure  that  the  system 
failure  rates  involving  common  element  failures  are  correct. 

As  a final  consequence  of  the  dependency  simplification,  the  states 
involving  unmodeled  transitions  will  not  appear  in  the  aggregated 
operational  state  of  the  baseline  truncation  model.  Ultimately,  the 
computed  probability  of  the  upper  bound  state  will  now  be  too  low.  It 
should  be  noted  that  the  upper  bound  state  is  also  low  because  of  splitting 
the  system  into  separate  section  models.  The  baseline  truncation  technique 
assumes  that  all  system  elements  are  included  in  the  model.  This  is  not 
true  in  our  separate  section  approach.  Other  techniques  are  needed  to 
estimate  a usable  probability  for  the  upper  bound  state.  For  the  refined 
configuration  study,  the  lower  reliability  bound  values  were  used  to 
evaluate  the  system. 

5.4.1  Critical  Assumptions 

The  system  elements  in  each  physical  enclosure  were  treated  together  for 
modeling  purposes.  This  includes  the  local  power  supply  and 
communication-related  elements.  A separate  section  model  was  created  for 
each  type  of  enclosure.  The  key  system  functions  performed  by  the  section 
model  elements  are  shown  in  table  5.4. 1-1.  Three  separate  versions  of  the 
section  models  were  created  for  this  evaluation.  These  versions  covered 
the  safety,  mission,  and  sustained  operational  capability  failure 
conditions.  Additionally,  some  of  the  section  models  had  a version  for 
each  of  the  data  distribution  options,  mesh  network  or  bus. 

The  refined  configuration  models  treated  four  new  situations  that  were 
different  than  the  candidate  architecture.  One  difference  in  the  mesh 
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Table  5.4. 1-1.  Section  Modeling  Allocation 


Section 

System  function 

Loss  effect 

Forward 

Pitch  command  sensing 

Safety 

Roll  command  sensing 

Safety 

Yaw  command  sensing 

Safety 

Flap  command  sensing 

Mission 

FTP  A computing 

Safety 

Mid 

Body  rate  sensing 

Safety 

Body  acceleration  sensing 

Safety 

Canard  actuation 

Safety 

Leading  edge  actuation 

Mission 

Nose  wheel  actuation 

Mission 

Tail 

Rudder  actuation 

Safety 

Right 

Ftaperon  actuation 

Safety 

wing 

Trailing  edge  flap 
actuation 

Mission 

Outboard  wing  acceleration 
sensing 

Mission 

Mid  wing  acceleration 
sensing 

Mission 

Inboard  wing  acceleration 
sensing 

Mission 

network  option  was  the  likelihood  of  system  failures  involving  single 
network  operation.  The  refined  configuration  has  fewer  root  links  than  the 
candidate  system.  Thus  the  probability  of  a permanent  loss  of  an  entire 
network  is  much  higher  than  it  was  in  the  candidate  architecture.  Once  an 
entire  network  becomes  inoperative,  failure  of  a critical  sensor  or  a 
communication  device  on  the  remaining  network  causes  a loss  of  safety.  In 
the  first  case  the  two  remaining  sensors  disagree,  and  in  the  second  case 
no  critical  sensors  or  actuators  are  accessible  during  the  subsequent 
network  repair. 

All  of  the  elements  involved  in  the  single  network  operation  are 
conveniently  contained  in  the  FORWARD  model  (table  5.4. 1-1).  The 
connection  paths  to  the  network  depend  on  the  FTP  channels,  the  Nl/root 
links,  the  root  nodes,  and  the  electric  power  sources.  The  failure  of  any 
one  of  these  elements  will  affect  one  of  the  connections  to  the  two 
networks.  Certainly  two-failure  sequences  will  therefore  eliminate  an 
entire  network.  The  probability  of  single-network  operation  is  determined 
exclusively  with  the  FORWARD  model. 

Another  new  modeling  situation  was  operation  of  the  mesh  network  system 
with  MID  enclosures  cross  connected  to  each  network.  The  purpose  of  the 
cross  connection  is  to  allow  the  skewed  sensors  to  be  accessed  from  the 
other  network  to  eliminate  vulnerability  to  temporary  exhaustion.  It  was 
assumed  that  I/O  activity  was  reconfigured  by  the  application  immediately 
after  failures,  which  made  the  system  vulnerable  to  temporary  exhaustion. 
With  this  kind  of  fault  reaction  in  operation  only  a few  two-failure 
conditions  leave  the  system  vulnerable  to  motion  sensor  temporary 
exhaustion.  These  situations  occur  when  certain  pairs  of  MID  nodes  or  node 
and  DIU  combinations  have  failed.  The  MID  section  models  handle  these 
situations  explicitly. 


The  mesh  network  option  MID  area  enclosures  are  also  unique  because  they 
are  connected  to  two  electrical  power  sources.  Therefore  power  source 
failures  have  no  effect  on  MID  area  devices  until  both  sources  for  a set  of 
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DIUs  are  lost.  However,  when  this  happens  redundancy  is  dramatically 
reduced.  For  the  mesh  network  power  connection  layout,  this  event 
coincides  with  the  loss  of  a single  network.  Power  source  failures  leading 
to  this  special  situation  are  the  only  important  ones  for  the  HID  devices. 
Therefore  only  electrical  failures  that  fall  in  this  category  are  modeled. 

The  final  new  situation  involves  changes  in  the  surface  actuator 
configuration  and  operation.  The  additional  redundancy  and  interface 
operation  changes  were  intended  to  produce  fail-operational/fail-off 
capability  for  each  surface.  This  means  that  the  controller  and 
communication  device  failures  cannot  affect  safety  until  the  fourth  failure 
level  except  for  temporary  exhaustion  situations.  Similarly,  these 
failures  can't  affect  mission  capability  until  the  second  failure  level. 
The  refined  configuration  modeling  effort  assumed  that  this  fail- 
operational/fail-off  capability  was  perfect  and  took  advantage  of  model 
truncation  at  the  third  failure  level  to  greatly  simplify  the  safety 

models . 

Propulsion  system  device  criticality  assumptions  were  different  for  the 
refined  configuration.  Some  of  the  differences  were  due  to  the 
configuration  changes  between  the  candidate  system  and  the  refined 
configuration,  while  other  differences  were  due  to  the  functionality 
changes  made  during  the  propulsion  system  review  effort.  The  following 
subsection  outlines  the  major  differences. 

One  change  in  functionality  occurred  in  inlet  sensing.  The  candidate 
evaluation  assumed  that  a loss  of  inlet  sensors  reduced  performance  to  the 
normal  level  as  defined  in  section  3.  For  the  refined  evaluation,  loss  of 
the  sensors  degrades  supersonic  performance  somewhat  but  supersonic 
operation  is  still  possible.  The  assumption  is  that  the  system  failure 
condition  resulting  from  the  degraded  supersonic  performance  falls  in  the 
full  mission  capability  category. 
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Another  change  was  in  the  engine  sensing  area.  In  the  candidate  system, 
full  performance  capability  was  available  with  four  of  the  five  sensor 
types.  The  missing  sensor  value  could  be  satisfactorily  synthesized  from 
the  remaining  sensor  values.  In  the  refined  evaluation,  the  fan  speed,  the 
burner  pressure,  and  the  afterburner  pressure  are  needed  to  provide  normal 
performance  capability.  Compressor  speed  and  fan  turbine  inlet  temperature 
provide  capability  at  the  full  performance  level.  The  analytic  redundancy 
method  is  still  used  for  failure  detection  and  identification  among  the 
engine  core  sensors. 

The  assumed  consequences  of  guide  vane  actuation  failures  were  different  in 
the  refined  configuration.  Loss  of  fan  or  compressor  guide  vane  actuation 
led  to  loss  of  normal  capability  in  the  candidate  evaluation.  The  same 
situation  in  the  refined  evaluation  results  only  in  a loss  of  full 
performance  capability,  which  is  less  serious. 

The  failure  assumptions  for  the  nozzle  area  control  actuator  are  changed 
for  the  refined  evaluation.  The  candidate  evaluation  assumption  was  that 
failure  resulted  in  normal  capability,  but  in  the  refined  evaluation 
failure  reduced  performance  to  the  low  capability  level.  Thus,  nozzle  area 
control  is  more  critical  in  the  refined  evaluation. 

Not  all  of  the  changes  in  the  group  B section  models  are  due  to  the 
propulsion  system  reevaluation.  In  the  refined  configuration  the  group  B 
FTP  controls  both  engines.  Failure  of  three  of  the  four  channels  therefore 
leads  to  loss  of  safety.  Failure  of  two  of  the  four  channels  is  a cause 
for  loss  of  sustained  operational  capability.  Because  it  accesses  the 
safety-critical  air  data  sensors,  the  group  B network  is  vulnerable  to  the 
single  network  failure  situation.  It  should  be  noted  that  in  the  refined 
evaluation  the  static  and  total  air  pressure  sensors  were  explicitly 
modeled  as  mission  critical  instead  of  safety  critical. 

Another  difference  in  the  refined  evaluation  was  that  the  propulsion 
devices  and  sensors  were  assumed  to  be  invulnerable  to  mesh  network 
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temporary  exhaustion.  This  means  that  the  propulsion  system  control  laws 
are  mechanized  so  that  commands  can  be  interrupted  for  short  periods.  As  a 
result,  loss  of  commands  to  the  propulsion  actuators  during  network  repair 
causes  at  most  a slight  hesitation  in  engine  acceleration  or  deceleration. 
This  is  different  from  the  flight  control  assumption,  in  which  interruption 
of  control  commands  to  the  unstable  aircraft  causes  loss  of  safety. 


5.4.2  Results 

The  results  of  the  safety  model  evaluation  are  summarized  in  table  5.4. 2-1. 
The  loss  of  safety  probability  is  dominated  by  group  A device  failures. 
Elements  in  group  B have  a smaller  effect  on  safety.  For  this  reason  bus 
option  versions  were  not  created  for  several  group  B safety  models. 
Nevertheless,  the  table  shows  that  both  refined  option  configurations  meet 
the  system  safety  requirement.  Failure  situations  involving  rare 
mechanical  actuator  jams  and  loss  of  both  hydraulic  systems  are  the  largest 
contributors  to  unreliability.  These  results  differ  from  those  of  the 
candidate  architecture  because  of  the  absence  of  the  special  surface 
control  failure  sequences  and  a large  reduction  in  the  likelihood  of  body 
motion  sensor  temporary  exhaustion.  This  is  expected  because  the  changes 
to  the  system  are  an  attempt  to  alleviate  precisely  those  problems. 

For  the  mesh  network  option,  the  two  largest  contributors  to  unreliability 
are  temporary  exhaustion  failure  of  the  primary  surface  actuator  channels 
and  loss  of  FTP  channels.  (The  FTP  channel  failure  sequence  has  the  same 
likelihood  in  both  options).  Both  of  these  situations  involve 
three-element  failure  sequences. 

The  new  single  network  operation  failure  situation  is  not  negligible,  but 
doesn't  appear  to  be  a significant  problem.  As  mentioned  previously,  it 
would  be  very  easy  to  add  a few  root  link  connections  to  improve  the 
network  access  redundancy.  The  main  reason  for  four  connections  in  the 
network  option  was  to  facilitate  comparison  with  the  bus  option. 
Nevertheless,  the  system  as  defined  easily  satisfies  the  reliability 

requirement . 
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The  table  shows  that  the  bus  option  is  not  vulnerable  to  any  of  the  special 
network  failure  modes  such  as  temporary  exhaustion  or  nearly  coincident 
sensor-network  recovery.  On  the  other  hand,  certain  functional  blocks  in 
the  bus  option  did  have  higher  unreliability  due  to  failure  sequences 
involving  permanent  bus  failures.  These  include  the  FORWARD  area  sensors 
and  the  MID  area  sensors. 

The  comparison  between  MID  sensors  in  table  5. 4. 2-1  is  affected  by  more 
than  just  the  central  bus  failure  dependency.  The  mesh  network  values  are 
also  better  because  of  the  dual  power  source  connection  to  each  DIU  and  the 
cross  connection  of  each  DIU  to  both  networks.  These  special  features 
further  enhance  the  benefit  of  the  mesh  network  option  compared  to  the  bus 
option  in  the  table. 

The  unreconf igurable  bus  introduces  a new  central  dependency  aspect  to  the 
reliability  model.  However,  note  that  even  though  the  unreliability  of 
some  functional  groups  is  worse  in  the  bus  option,  the  system  requirement 
is  still  easily  satisfied.  The  elements  that  play  a role  in  the  central 
bus  reliability  are  the  FTP  channel,  the  FTP  bus  interface,  the  bus  media 
(wires,  production  break  connectors,  etc.),  and  the  individual  DIUs.  Of 
these  elements,  the  bus  media  unreliability  is  insignificant.  The  key 
individual  contributor  to  central  bus  failures  is  the  FTP  channel.  Its 
unreliability  overshadows  the  other  elements.  As  mentioned  previously, 
additional  bus  interfaces  could  be  added  to  other  FTP  channels,  just  as 
additional  network  interfaces  could  be  added  in  the  mesh  network  option. 
This  would  greatly  reduce  the  likelihood  of  central  bus  failures. 

The  DIUs  or  bus  interface  units  (BIU)  connect  the  devices  to  the  central 
bus.  Without  special  design  features,  certain  single  DIU  failures  will 
bring  the  entire  bus  down.  An  active  DIU  failure  mode  was  modeled  for  the 
bus  option,  which  causes  the  loss  of  all  devices  connected  over  that  bus. 
Because  of  this  hazard,  practical  bus  designs  for  critical  systems  have 
special  design  features  to  make  central  failures  very  unlikely.  However, 
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Table  5.4.2-1.  Safety  Model  Results  (*10  ~7),  3-hr  Flight 


Sequence 

Two  network 

Four  bus 

Exhaustion 

• Forward  sensors 

0.00034 

0.0032 

• Mid  sensors 

0.00040 

0.029 

• FTP 

0.034 

0.034 

• Surface  jam 

0.24 

0.24 

♦ Hydraulic  supply 

0.18 

0.18 

• Air  sensors 

0.0012 

• Engine-out  throttle 

0.0072 

• Both  engines 

0.0016 

• Surface  pair  safe 

0.00014 

0.00014 

Nearly  coincident 

• Like  sensor 

0.00027 

0.00027 

• FTP 

0.000144 

0.000144 

• Sensor  network 

0.0058 

- 

• Dual  network 

0.0034 

Temporary  exhaustion 

• Forward  sensors 

0.00083 

• Mid  sensors 

0.00012 

— 

• Surface  controllers 

0.013 

— 

• Air  sensors 

0.0012 

— 

Single  network 

0.0112 

- 

Total 

0.501 

♦ 

Not  calculated 


this  study  assumed  no  special  design  features  in  order  to  simplify  the 
comparison  between  the  mesh  network  and  bus  option.  To  assess  the 

resulting  hazard,  a nominal  value  of  10  percent  active  DIU  failures  was 
assumed  in  the  models.  A sensitivity  study  showed  that  the  table  5.4. 2-1 
results  were  not  significantly  affected  when  the  active  fault  percentage 
was  varied  from  1 percent  to  50  percent. 

As  mentioned  earlier,  group  B elements  have  a small  effect  on  system 
safety.  The  largest  group  B contributor  is  the  failure  of  the  FTP.  This 
three-failure  sequence  results  in  a total  loss  of  thrust  control.  An 
interesting  failure  condition  is  listed  in  the  table  as  engine-out  - 
throttle.  This  sequence  is  the  shutdown  of  an  engine  for  some  reason 

followed  by  the  failure  of  one  of  the  two  remaining  throttle  position 
sensors.  The  engine-out  - throttle  situation  also  results  in  a loss  of 
thrust  control.  It  should  be  noted  that  the  group  B network  contributes  to 
the  single  network  failure  situation.  These  kinds  of  failure  conditions 
occur  when  access  to  an  entire  network  is  lost  followed  by  a failure  of  one 
of  the  safety-critical  airflow  sensors. 

The  contribution  to  loss  of  safety  due  to  failures  in  both  engines  was 
estimated  by  combining  the  results  of  several  section  models.  The  results 
of  the  separate  section  models  that  computed  loss  of  normal  performance 
capability  in  one  engine  were  carefully  combined  to  provide  this  figure. 
Correct  combination  of  results  was  very  difficult  because  much  effort  was 
required  to  adjust  the  section  model  results  to  cover  only  mutually 
exclusive  situations.  (Of  course,  the  error  introduced  by  ignoring  this 
adjustment  step  turned  out  to  be  insignificant.) 


The  results  of  the  full  mission  capability  evaluation  are  presented  in 
table  5. 4. 2-2.  Unlike  the  loss  of  safety  situation,  the  mission 
unreliability  is  dominated  by  the  group  B elements.  Comparison  of  the  mesh 
network  and  bus  options  shows  that  the  network  does  better  in  mission 
reliability  but  that  both  systems  meet  the  system  requirements.  A key 
assumption  in  this  evaluation  is  that  the  mission  can  be  continued  after 
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Table  5A.2-2.  Mission  Model  Results  (xIO  ~4),  1-hr  Flight 


Sequence 

Two  network 

Four  bus 

Forward  sensing 

0.00022 

0.00059 

Mid  actuation 

0.0009 

0.0038 

Tail  actuation 

0.0015 

0.0027 

Wing  actuation/sensing 

0.0076 

0.014 

Air  sensing 

0.00016 

0.00038 

Inlet  actuation 

0.099 

0.100 

Nozzle  actuation 

0.099 

0.100 

Engine  devices 

0.205 

0.212 

Electric  power  supply 

0.00015 

- 

Hydraulic  power  supply 

0.00002 

0.00002 

Single  network 

0.0015 

- 

Central  bus  failure* 

- 

0.0061 

Total 

0.415 

0.440 

Includes  electric  power  and  FTP  channel 


one  of  the  two  hydraulic  systems  fail  because  all  actuators  are  dual.  If 
loss  of  a single  hydraulic  system  is  a mission-abort  condition,  hydraulic 
supply  failures  would  dominate  the  mission  criteria. 

The  predominant  mission  failures  were  special  single-failure  situations 
involving  the  propulsion  actuators.  Specific  causes  were  control  valve 
jams  and  uncovered  position  sensor  and  valve  drive  failures.  These 
failures  prevent  device  control  and  result  in  the  loss  of  full  performance 
capability  for  its  propulsion  system. 

A key  assumption  reflected  in  these  results  is  that  a mission  can  be 
continued  after  two  safety-critical  sensors  or  two  FTP  channels  are  lost. 
The  system  is  still  able  to  perform  all  functions,  but,  as  in  the  hydraulic 
system  situation,  one  more  failure  causes  loss  of  the  aircraft.  If  these 
situations  are  cause  for  mission  abort,  several  more  two- failure  sequences 
will  contribute  to  mission  unreliability.  The  central  effect  of  bus 
failures  is  more  apparent  in  this  model  than  in  the  safety  model.  Like  the 
safety  evaluation,  the  special  features  of  the  MID  configuration  make  the 
network  option  MID  sensors  more  reliable. 

Table  5. 4. 2-3  summarizes  the  results  of  the  sustained  operational 
capability  evaluation  for  the  refined  configuration  options.  The  network 
option  also  has  the  advantage  in  this  comparison.  The  dominant  failure 
sequence,  given  the  assumed  operational  rules  described  in  section  5.4.1, 
is  loss  of  a single  hydraulic  system.  With  only  two  systems,  a second 
hydraulic  failure  causes  loss  of  the  aircraft.  Therefore  the  aircraft 
requires  maintenance  before  dispatch  on  another  combat  mission.  This 
single  failure  situation  masks  somewhat  the  effects  of  other  system  failure 
sequences . 


The  ground  rules  for  dispatch  in  this  sustained  capability  model  make  the 
safety-critical  sensors  and  FTP  channels  play  a direct  role.  Unlike  the 
mission  model,  failure  of  either  two  FTP  channels  or  two  safety-critical 
sensors  is  a system  failure  condition.  It  should  be  pointed  out  that  in 
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Table  5. 4. 2-3.  Sustained  Capability  Results  (xIO  ),  50  hr 


Sequence 

Two  network 

Four  bus 

Forward  sensing 

0.019 

0.053 

FTP 

0.184 

0.184 

Mid  sensing/actuation 

0.022 

0.108 

Wing  sensing/actuation 

0.190 

0.350 

Tail  actuation 

0.037 

0.066 

Air  sensors 

0.033 

NC 

Inlet  actuation 

0.102 

NC 

Nozzle  actuation 

0.102 

NC 

Engine  devices 

0.304 

NC 

Hydraulic  power  supply 

0.450 

0.450 

Single  network 

0.015 

— 

Central  bus  failure 
(A  only) 

0.024 

Total 

1.46 

NC 

the  sustained  operational  capability  results  the  FTP  channel  and  electric 
power  failure  combinations  are  listed  as  FTP  failure  sequences,  whereas  in 
the  mission  model  they  are  shown  as  central  bus  failures.  The  central  bus 
failure  entry  in  the  sustained  capability  table  includes  all  failure 
sequences  resulting  in  loss  of  two  buses  except  for  FTP  channel  and 
electric  power  source  combinations. 

Sensitivity  Study 

A limited  study  was  performed  to  assess  the  sensitivity  of  the  reliability 
evaluation  results  to  the  model  parameters.  The  dominant  failure  sequences 
in  the  safety  models  and  the  mission  models  were  examined  to  see  how  model 
parameters  such  as  component  failure  rates,  active  failure  fractions, 
uncovered  failure  fractions,  etc.,  entered  into  the  system  unreliability. 
The  limited  assessment  made  use  of  the  fact  that  the  group  A elements 
dominate  the  safety  reliability  and  that  the  group  B elements  are  most 
important  to  mission  capability. 

To  judge  whether  a parameter  was  critical,  its  value  was  increased  by  an 
arbitrary  multiple  and  the  section  model(s)  recalculated  to  provide  the 
effect  on  reliability.  If  the  resulting  change  in  reliability  exceeded  the 
system  constraint  the  parameter  was  critical.  The  multiple  assigned  to  the 
parameter  was  based  on  how  well  it  was  known.  Parameters  such  as  component 
total  failure  rate  were  increased  by  a factor  of  two.  When  the  parameter 
was  not  as  well  known,  such  as  an  active  failure  fraction  or  percentage  of 
uncovered  failures,  it  was  increased  by  an  order  of  magnitude.  Finally, 
for  certain  very  unlikely  failure  modes,  such  as  the  probability  of  rare 
mechanical  jams,  the  likelihood  was  increased  by  two  orders  of  magnitude. 
The  intent  was  to  vary  the  parameters  in  a way  that  reflected  the  amount  of 
uncertainty  in  the  parameters.  If  variation  in  the  model  parameters  causes 
a violation  of  reliability  constraints,  small  variations  in  better  known 
values  are  cause  for  the  same  level  of  concern  as  larger  variations  in  less 
well  known  values. 
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A look  at  the  most  likely  safety  sequences  using  the  above  criteria  shoved 
two  significant  parameters.  One  was  the  fraction  of  surface  actuation 
failures  leading  to  a jammed  surface.  The  assumed  equivalent  nominal 
failure  rate  for  this  mode  corresponds  to  an  extremely  improbable  event.  A 
nominal  value  of  one  event  in  10E+9  hours  was  used.  The  sensitivity  study 

shoved  that  this  value  could  be  increased  by  only  a factor  of  3 before  the 

safety  constraint  vas  violated.  This  margin  seems  lov  for  such  a rarely 
occurring  parameter. 

The  other  critical  parameter  for  safety  vas  the  failure  rate  of  the 
hydraulic  pover  system.  There  are  tvo  hydraulic  pover  systems  on  the 

" aircraft.  The  sensitivity  study  shoved  that  the  safety  constraint  vas 

violated  if  the  failure  rate  vas  increased  by  a factor  of  2.  The  reduced 
margin  on  this  parameter  vould  indicate  a need  for  close  monitoring  of  the 
development  of  the  system  or  perhaps  alternative  design  provisions. 

An  analysis  of  the  most  likely  mission  failure  sequences  also  pointed  out 
tvo  critical  parameters.  Both  parameters  contributed  to  the  propulsion 
system  single-failure  situations.  The  first  parameter  vas  the  fraction  of 
propulsion  actuator  control  valve  failures  leading  to  a jammed  valve.  Such 
a failure  caused  central  redundancy  management  to  safe  the  actuator.  A 
nominal  value  for  this  failure  mode  vas  one  event  in  10E+6  hours.  The 
sensitivity  study  shoved  that  an  increase  in  the  value  by  a factor  of  3.5 
was  enough  to  violate  the  mission  capability  criterion.  Again  this  appears 
to  be  insufficient  margin  for  a parameter  that  is  not  veil  knovn. 


The  second  critical  mission  parameter  vas  coverage  of  the  actuator 
elements.  A nominal  coverage  value  of  0.99  vas  assumed  for  the  position 
sensor  and  the  drive  elements.  If  this  value  vere  reduced  belov  0.95  the 
mission  capability  constraint  criterion  vould  be  violated.  Because  this 
does  not  provide  an  order-of-magnitude  margin,  this  parameter  is  therefore 
critical  to  the  mission  success  for  the  refined  configuration. 
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5.4.3  Transient  Threat 


The  reliability  evaluation  described  to  this  point  deals  only  with  the 
effects  of  permanent  faults.  Another  concern  for  highly  reliable  systems 
is  the  effect  of  transient  failures.  A transient  failure  is  characterized 
by  faulty  behavior  of  an  element  for  some  finite  time  followed  by 
fault-free  operation.  The  effect  of  a transient  may  persist  after  the 
fault  disappears,  for  example,  in  an  erroneous  data  value.  For  redundant 
systems,  transients  are  primarily  a redundancy  management  concern.  If  the 
effect  of  the  transient  failure  were  contained  by  the  redundancy  management 
process,  the  ideal  action  would  be  to  wait  for  the  transient  to  disappear. 

Unfortunately,  it  is  not  possible  to  tell  whether  a fault  is  transient  or 
permanent. 


The  reaction  of  a specific  redundancy  management  process  to  a transient  is 
design  peculiar.  A major  problem  encountered  when  designing  for  transients 
is  characterization  of  the  threat.  Because  they  disappear  after  a short 
time,  solid  operational  data  on  transient  rates  and  duration  are  scarce.  A 
limited,  parametric  evaluation  of  the  transient  threat  was  performed  during 
the  refined  configuration  study.  A benefit  of  this  kind  of  transient  study 
is  that  it  shows  the  system  designer  the  effectiveness  of  the  redundancy 
management  processes,  including  the  effect  of  certain  internal  process 
parameters. 

Sensor  and  actuator  redundancy  management  processes  must  handle  normal 
device  mismatches  to  satisfy  stringent  missed  alarm,  false  alarm,  and 
failure  transient  criteria.  Complex  filtering  processes  are  commonly  used 
for  this  purpose.  These  characteristics  make  these  processes  less 
vulnerable  to  transients.  On  the  other  hand,  the  computing  redundancy 
management  requires  the  redundant  channels  to  maintain  strict  instruction 
synchronism  and  bit-for-bit  output  agreement.  For  this  reason  computing 
transients  were  modeled  in  this  limited  evaluation  of  the  IAPSA  II  system. 
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Since  the  evaluation  revolves  around  the  redundancy  management  behavior, 
some  key  features  of  the  FTP  FDIR  process  were  modeled.  These  key  features 
include  exact  voting  of  all  redundant  channel  outputs  every  computing 
cycle,  maintenance  of  instruction  synchronism  in  all  redundant  channels, 
and  periodic  self-tests  that  ensure  that  each  channel's  memory  agrees  with 
the  others.  A key  study  assumption  is  that  the  transient  affects  only  one 
of  the  redundant  channels.  If  more  than  one  computing  channel  is  affected 
by  the  transient  event,  it  is  not  possible  to  prevent  errors  from 
propagating  to  the  rest  of  the  system.  The  result  is  catastrophic  system 
failure. 

The  transient  fault-FDIR  interaction  model  is  shown  in  figure  5.4. 3-1.  A 
state  diagram  for  the  system  as  it  responds  to  the  transient  event  is  shown 
at  the  top  of  the  figure.  A timeline  showing  when  the  FDIR  processes  take 
place  during  cyclic  execution  of  the  application  is  shown  at  the  bottom  of 
the  figure.  The  transient  event  modeled  in  this  study  causes  an  error  that 
does  not  disappear  by  itself.  A transient  event  that  changes  a memory 
value  corresponding  to  a program  constant  would  cause  this  kind  of 
behavior. 

The  model  in  figure  5. 4. 3-1  shows  three  possible  transitions  after  the 
transient  event  occurs.  The  transition  marked  "scrub"  indicates  return  to 
normal  operation,  which  occurs  if  the  periodic  background  FDIR  process 
corrects  the  error  before  its  use  in  the  system  computation.  There  are  two 
possible  outcomes  if  the  error  is  used  by  the  computation  before  this 
"memory  scrub."  One  transition  models  the  case  in  which  the  affected 
channel  produces  an  output  that  disagrees  with  the  other  channels,  while 
the  other  transition  models  a loss  of  synchronization  by  the  affected 
channel.  There  is  a big  difference  in  the  effect  of  these  transitions  on 

the  system. 

Loss  of  synchronization  is  critical  for  the  IAPSA  system  because  of  the 
intense  time-critical  workload.  The  normal  FTP  FDIR  reaction  is  to 
activate  a resynchronization  process.  The  resynchronization  process  brings 
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Legend: 

1 Vulnerable  to  nearly  coincident 

2 Vulnerable  to  transient  exhaustion 


1 



Vote  FDIR  ||  Compute  Background 

Vote  FDIR 

Vote  outputs 
(part  of  I/O) 
activity 


Application 

computing 


Synch  check 
Vote  check 
Reconfigure 
(if  needed) 


Self  tests 
Detailed  error 
analysis 


Figure  5.4.3 - 1 . Simplified  Model 
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the  channels  back  into  instruction  synchronism  and  then  aligns  all  volatile 
memory  by  voting  it  through  the  data  exchange.  This  last  step  guarantees 
that  the  execution  state  of  the  channel  being  promoted  is  identical  to  that 
of  the  other  channels. 

The  problem  is  that  memory  alignment  must  be  completed  before  application 
execution  can  resume.  Rough  calculations  indicate  that  even  with  very 
optimistic  assumptions,  such  as  data  exchange  operation  at  the  hardware 
limit  and  a minimum  system  RAM  implementation,  the  time  required  for 
channel  restart  is  a major  fraction  of  the  IAPSA  II  minor  frame.  Thus  it 
is  assumed  that  channel  restart  cannot  be  accomplished  in  the  available 
time.  Loss  of  synchronization  in  a channel  is  just  like  a permanent 
channel  fault  for  the  rest  of  the  flight.  Resynchronization  might  be 
possible  using  a strategy  of  terminating  the  mission-critical  functions  at 
pilot  discretion  before  attempting  resynchronization.  Sequential  restart 
of  the  mission-critical  functions  might  then  be  possible  after 
resynchronization.  This  strategy  and  the  resulting  reliability  trades 
between  mission  capability  and  safety  were  not  investigated  further. 


The  transient  study  therefore  assumes  that  the  recovery  action  for  a lost 
synch  fault  is  to  retire  the  channel.  Before  recovery,  the  quad  system  is 
vulnerable  to  a nearly  coincident  fault  in  the  same  way  that  a channel  is 
vulnerable  while  recovering  from  a permanent  fault.  System  sensitivity 
data  were  generated  using  the  percentage  of  faults  that  cause  a loss  of 
synch  as  a parameter.  The  other  transient  faults  were  assumed  to  cause 
output  disagreement. 

The  modeled  recovery  sequence  is  different  for  faults  that  cause  output 
disagreement.  First,  the  "soft"  fault  may  take  longer  to  diagnose  than 
loss  of  synch.  During  this  period  before  disabling  the  channel,  the  system 
is  vulnerable  to  another  nearly  coincident  transient  or  permanent  fault. 
Once  the  channel  is  disabled,  the  FDIR  process  periodically  checks  to  see 
if  the  channel  is  still  producing  errors.  If  not,  the  channel  is  restored 
to  operation.  In  our  model  the  channel  is  restored  once  the  periodic 
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background  process  has  corrected  the  error.  Vhen  three  FTP  channels  remain 
in  operation  and  one  of  them  is  waiting  for  transient  restoration,  the 
system  is  vulnerable  to  a transient  or  permanent  fault.  This  situation, 
termed  transient  exhaustion,  results  in  a disagreement  between  the  two 
voting  channels.  Since  FDIR  is  unable  to  determine  which  channel  is  at 
fault,  system  loss  is  assumed. 

The  transient  model  for  the  loss  of  safety  failure  condition  was  evaluated 
using  ASSIST  and  SURE.  The  model  transitions  were  all  approximated  using 
exponential  distributions.  This  is  a fairly  coarse  but  reasonable 
simplification  for  this  sensitivity  study.  The  nominal  assumptions  for  the 
transient  model  are  as  follows.  The  mean  time  between  the  transient  and 
the  use  of  the  corrupted  data  in  the  computation  is  5 milliseconds.  A 
nominal  value  of  50  percent  of  transient  faults  lead  to  a loss  of 
synchronization.  The  ratio  of  the  memory  scrub  period  to  the  memory  use 
period  was  8.  The  mean  channel  recovery  time  was  20  milliseconds.  Note 
that  with  these  nominal  model  parameters,  the  probability  of  loss  of  safety 

due  to  FTP  failures  is  significantly  larger  than  the  value  shown  in  figure 
5.4. 2-1. 

The  sensitivity  to  the  rate  of  transient  faults  is  shown  in  figure  5.4. 3-2. 
The  figure  shows  that  transients  having  the  characteristics  of  our  model 
can  become  the  dominating  failure  sequence  if  their  rate  of  occurrence  is 
high.  Figure  5.4. 3-3  presents  the  sensitivity  of  the  system  to  the  fraction 
of  transient  faults  that  cause  a channel  to  go  out  of  synch.  Failures  that 
cause  a loss  of  synch  are  naturally  more  critical  because  the  channel  is 
potentially  lost  for  the  remainder  of  the  flight. 

The  effectiveness  of  the  modeled  memory  scrub  process  is  shown  in 
figure  5.4. 3-4.  This  process  corrects  the  faulty  data  before  they  are  used 
in  the  system  computation.  The  results  imply  that  the  process  is  not  very 
effective  until  its  cycle  rate  approaches  the  cycle  rate  of  the  using 
process.  This  is  a reasonable  result,  but  the  ability  to  achieve  high 
background  process  cycle  rates  in  a reasonably  loaded  system  is  highly 
questionable. 
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Figure  5. 4. 3-3.  Loss  of  Sj 
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Based  on  the  nominal  conditions  assumed  for  the  study,  figure  5. 4. 3-5  shows 
that  the  increased  likelihood  of  nearly  coincident  failures  does  not 
significantly  affect  overall  unreliability  until  recovery  times  exceed 
about  1 second.  (The  figure  shows  the  result  for  soft  faults;  the  data  for 
loss  of  synch  faults  are  similar.)  It  should  be  noted  that  these  results 
assume  that  the  failed  channel  is  not  sending  bad  data  on  one  of  the  two 
networks.  The  system  can  tolerate  the  latter  situation  for  only  a few 
application  cycles. 

These  parametric  results  point  out  the  need  to  characterize  the  transient 
environment  and  FDIR  interaction  in  the  system.  Because  the  transient 
environment  in  flight  operation  is  critical,  this  characterization  will 
require  inflight  measurements  on  flight-type  hardware.  The  study  shows 
that  certain  key  parameters  dramatically  affect  system  results.  These  key 
parameters  values  must  eventually  be  measured  in  the  system.  With  good 
environment  data,  more  detailed  modeling  of  the  system  FDIR  processes  could 
be  used  to  more  accurately  define  the  threat.  Determination  or 
verification  of  the  key  parameters  of  the  resulting  models  will  be  a 
difficult  task. 

5.5  Timing  Prediction 

In  addition  to  the  reliability  analysis,  a simplified  performance  estimate 
was  made  for  the  refined  configuration.  This  estimate  allows  evaluation  of 
the  success  of  the  changes  made  to  the  candidate  architecture  to  improve 
growth  capability.  Ideally,  a performance  simulation  such  as  that 
described  in  section  4.2  would  be  conducted  for  the  refined  configuration. 
However,  time  did  not  allow  such  an  effort  to  be  accomplished  in  this 
study. 

The  timing  estimate  is  dependent  on  how  the  application  computing  and  I/O 
activity  is  organized  by  the  designer.  Ideally,  the  application  would  be 
organized  to  keep  the  application  functions  independent.  This  independence 
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eases  development  and  verification  effort,  especially  when  the  control 
functions  are  separated  into  less  critical  and  more  critical  functions. 
This  independence  will,  however,  cause  duplication  of  some  of  the 
processing  when  sensors  or  actuators  are  shared  between  functions.  For 
this  reason  processes  such  as  sensor  redundancy  management  and  computed 
state  estimates  are  shared  between  functions.  Preliminary  timing  estimates 
showed  that  further  compromises  were  needed  to  meet  the  heavy  loading  needs 
of  the  IAPSA  II  application  workload. 


Certain  ground  rules  were  used  to  organize  the  application  activity  to 
minimize  the  effect  of  its  demanding  requirements  on  the  candidate 
architecture.  First,  all  the  activity  with  a common  execution  rate 
requirement  was  grouped  together  in  a rate  group.  This  included  both 
computing  activity  and  I/O  activity.  Next  the  I/O  activity  for  a single 
rate  group  was  grouped  into  a single  request  containing  both  the  input 
commands  and  output  commands  for  a single  cycle.  As  a result,  there  was  an 
end-to-end  time  delay  of  approximately  one  cycle  period  from  sensor  read  to 
actuator  write.  By  comparison,  when  the  I/O  activity  is  organized  into 
separate  input  and  output  requests,  the  time  delay  can  be  less  than  a cycle 
period,  but  the  number  of  transactions  per  cycle,  and  hence  I/O  loading, 
nearly  doubles. 

A key  problem  was  the  limited  I/O  activity  concurrency  possible.  Once 
execution  of  an  I/O  request  reaches  a certain  point,  it  becomes  impractical 
to  suspend  it  for  a higher  priority  request.  Care  must  therefore  be  taken 
so  that  a low-priority  request  does  not  delay  a higher  priority  request.  A 
maximum  of  two  I/O  requests  can  be  accomplished  in  each  minor  frame  based 
on  the  preliminary  estimates.  For  this  reason,  the  activity  in  each  minor 
frame  of  application  execution  was  overtly  organized  so  that  any  requested 
I/O  activity  would  complete  before  the  next  request  by  a fast  hign-priori ty 
task.  This  was  accomplished  by  controlling  the  initial  phasing  of  the 
slower  rate  groups  with  respect  to  each  other.  For  example,  the  medium 
rate  group  was  started  in  minor  frame  one  and  repeated  every  other  minor 
frame  while  the  slow  rate  group  started  in  minor  frame  two  and  repeated 
every  fourth  minor  frame. 
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The  organization  ground  rules  used  for  the  candidate  system  were  used  for 
the  refined  configuration.  Although  steps  were  taken  to  reduce  the 
application  loading,  the  demands  on  the  system  were  still  large.  Key 
timing  data  for  this  configuration  are  shown  in  table  5.5-1.  The  changes 
in  this  data  compared  to  the  candidate  architecture  are  due  to  fewer  DIUs 
and  the  reallocation  of  computing  and  I/O  activity  between  groups.  Some 
minor  changes  were  assumed  in  the  command  and  response  frame  formats  to 
slightly  reduce  bus  overhead  traffic  and  data  exchange  loading.  On  other 
hand,  the  DIU  time  required  for  sensor  and  actuator  interface  functions  was 
increased  slightly,  to  more  realistic  values.  The  results  of  these  changes 
are  shown  in  table  5.5-2. 

Comparison  of  results  with  those  generated  manually  for  the  candidate 
architecture  shows  that  the  changes  were  successful.  For  comparison,  the 
candidate  values  were  59  percent  for  computing  and  76  percent  for  I/O 
activity.  It  should  be  noted  that  these  timing  results  are  based  on  the 
same  simplifying  assumptions  used  in  the  candidate  system  estimate.  Key 
assumptions  are:  (1)  no  chain  completion  delay,  (2)  slower  rate  processes 
can  be  evenly  split  into  independent  separate  processes,  and  (3)  growth 
capability  measures  how  much  the  activity  can  expand  uniformly  before 
timing  constraints  are  violated.  Assumption  1 ensures  that  there  is  no 
time  wasted  between  completion  of  the  I/O  activity  on  the  network  and  the 
start  of  chain  postprocessing  in  the  IOP.  Assumption  2 ignores  the 
application-specific  problems  inherent  in  dividing  up  an  application 

process. 

Experience  with  the  DENET  simulation  showed  that  the  task  switching 
overhead  resulted  in  a big  decrease  in  growth  capability.  The  timing 
estimate  produced  previously  was  therefore  adjusted  in  a simple  way  for  the 
resulting  overhead  if  the  system  utilization  were  increased  to  nearly  100 
percent.  This  included  an  estimate  of  the  effect  of  the  task  switches  in 
the  CP  and  the  IOP  that  would  occur  in  a system  that  was  nearly  fully 
loaded.  The  results  shown  in  parentheses  in  table  5.5-2  were  obtained  when 
a fixed  time  of  0.3  milliseconds  was  allowed  for  this  task  switching. 
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Table  5.5-1.  Refined  Configuration  Timing  Data 


Group 

Rate,  Hz 

No.  of 

transactions 

Computing  time, 
lisec 

100.0 

6 

990 

A 

50.0 

6 

4,793 1 

12.5 

- 

267 

! 100.0 

4 

1,050 

B 

50.0 

2 

94 

25.0 

4 

9,6872 

Organization  ground  rules  like  reference  configuration 

^ Manual  control  fully  active 
2 Trajectory  following  active 


6.0 


SMALL-SCALE  SYSTEM  TESTING 


This  section  outlines  the  objectives  and  presents  experiment  definitions 
for  the  small-scale  system  testing  effort.  The  small-scale  system  embodies 
key  features  of  the  IAPSA  II  design  that  will  be  evaluated  in  a limited 
experimentation  effort.  The  limited  effort  will  explore  a set  of  critical 
aspects  of  the  IAPSA  II  reference  configuration  architecture. 

The  small-scale  system  consists  of  a triple-channel  FTP  interfacing  with  a 
local  I/O  network  made  up  of  two  subnetworks.  Experimental  data  will  be 
obtained  for  two  purposes.  First,  certain  performance  estimates  obtained 
during  the  detailed  design  effort  will  be  verified.  Performance  simulation 
results  will  be  directly  compared  with  applicable  measurements  made  on  the 
small-scale  system.  Second,  certain  timing  characteristics  critical  to 
successful  operation  in  normal  and  faulted  situations  will  be  measured 
experimentally.  A limitation  of  this  small-scale  system,  of  course,  is 
that  system  level  interactions  (e.g.,  communication  between  the  flight 
control  group  and  the  engine  groups)  cannot  be  tested. 

The  small-scale  system  effort  is  feasible  because  of  the  availability  of 
fault-tolerant  processors  (FTP),  network  nodes,  and  interconnecting  links 
in  the  hardware  area  as  well  as  system  services  packages  in  the  software 
area.  A goal  of  this  effort  is  to  ensure  that  validation  issues  defined  in 
the  design/validation  concept  report  and  uncovered  during  the  detailed 
design  effort  are  evaluated  fully. 


The  rest  of  this  section  contains  a discussion  of  the  small-scale  system 
testing  objectives,  followed  by  a definition  of  experiments.  The  test 
configurations  are  described  along  with  the  test  control  strategy.  The 
section  concludes  with  a description  of  the  data  collection  and  analysis 

approach. 
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6.1 


Testing  Objectives 


The  general  objective  of  this  testing  is  to  characterize  the  timing 
performance  of  the  small-scale  system  under  normal  and  faulted  conditions. 
The  resulting  performance  measurements,  together  with  low-level  time 
elements  measured  by  the  building  block  developer,  will  allow  evaluation  of 
the  performance  capability  of  the  IAPSA  II  reference  configuration. 

Application  computing  and  I/O  activity  workload  simulation  is  used  to 
evaluate  the  small-scale  system.  Preliminary  workload  estimates  developed 
during  the  performance  modeling  effort  are  used  in  conjunction  with  the 
selected  sequencing  and  control  mechanisms  to  define  a suitable  application 
workload  simulation  for  the  small-scale  system. 

The  simulated  workload  approach  requires  only  a representative  test  system 
I/O  environment.  This  means  that  the  test  facility  need  not  perform  a 
high-fidelity  aircraft  or  engine  simulation  to  support  the  experiments 
envisioned  for  the  small-scale  system.  This  greatly  reduces  the  test 
facility  requirements. 

The  experimental  objectives  fall  into  two  major  categories.  The  first 
category  covers  measurements  dealing  with  the  performance  of  key  system 
services  operations;  the  second  category  measures  the  overall  performance 
of  the  application.  The  detailed  objectives  of  the  experiments  are 
presented  in  the  following  subsections. 

6.1.1  System  Timing  Characterization  - Normal  Conditions 

The  timing  characteristics  of  the  small-scale  system  will  be  measured  while 
it  executes  the  defined  application  workload.  The  application  workload 
corresponding  to  the  flight  control  configuration  of  the  IAPSA  II  reference 
configuration  is  used  to  characterize  key  system  timing  behavior. 

Input/Output  Request  Timing.  The  time  needed  to  execute  the  application 
I/O  activity  is  a key  component  of  a control  cycle.  The  performance  model 
estimates  may  have  been  optimistic  because  they  were  based  on  operation 
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near  the  hardware  limit.  The  small-scale  system  measurements  will  provide  a 
more  realistic  end-to-end  time  for  this  activity.  One  measurement  will 
determine  the  total  time  required  to  perform  the  I/O  activity.  Time  is 
measured  from  the  beginning  of  the  system  call  that  starts  the  I/O  activity 
until  the  data  is  available.  This  measures  all  intervening  system  overhead 
processing  time. 

Another  set  of  measurements  will  capture  the  system  overhead  time  needed  to 
transfer  output  data  in  preparation  for  an  I/O  request  or  to  transfer  input 
data  obtained  as  a result  of  an  I/O  request.  These  timing  elements  were 
not  included  in  the  performance  model.  Time  is  measured  from  the  beginning 
of  the  system  calls  that  starts  the  data  transfer  until  the  system  function 
is  complete  and  the  data  is  available.  The  amount  of  data  transferred  by 
these  calls  will  correspond  to  the  reference  configuration  flight  control 
I/O  traffic. 

Control  Cycle  Overhead.  The  total  end-to-end  system  processing  time  needed 
to  support  the  cyclic  application  execution  will  be  measured.  The 
measurement  will  be  made  in  a controlled  execution  environment  to  determine 
allowable  frame  rates  for  slow-time  testing.  The  key  service  operations 
are  processing  of  I/O  requests,  scheduling  and  dispatch  actions,  and  fast 
FDIR  processing.  The  I/O  request  time  components  discussed  previously  are 
contained  in  this  time.  I/O  processing  will  be  measured  in  two  situations: 
(1)  when  the  application  does  no  detailed  error  checking  and  (2)  when  the 
application  checks  the  error  status  of  every  transaction. 

Laboratory  Environment  Errors.  The  objective  is  to  characterize  the 
small-scale  system  testing  environment  in  terms  of  its  potential  for 
naturally  occurring  errors.  If  the  background  environment  causes  errors  in 
data  transferred  or  voted  via  the  data  exchange,  system  FDIR  actions  will 
result.  Similarly,  naturally  occurring  errors  due  to  noise,  and  so  forth, 
in  data  transferred  over  the  I/O  network  will  cause  I/O  network  manager 
actions.  Unless  errors  of  both  types  are  very  rare,  they  will  interfere 
with  small-scale  system  testing.  These  measurements  will  characterize  only 
the  normal  execution  environment  in  the  laboratory.  The  critical  issue  of 
naturally  occurring  errors  or  transients  in  the  flight  environment  can  only 
be  addressed  by  flight  testing. 
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6.1.2  Systea  Timing  Characterization  - Fault  Conditions 


Input/Output  Network.  Faults.  The  time  to  recover  from  a fault  on  the  I/O 
network  will  be  measured  from  fault  insertion  until  the  network  is  back  in 
service.  While  the  network  is  being  repaired,  the  application  does  not 
have  access  to  half  of  the  reference  configuration  sensors  and  actuators. 
In  addition  to  the  passive  link  failures  run  during  the  simulation  model 
experiments,  active  link  failures  and  active  and  passive  node  failures  will 
be  investigated.  In  addition,  the  AIPS  network  repair  strategy  has  been 
further  defined  since  the  simulation  experiments  were  defined.  As  a 
result,  the  small-scale  system  will  incorporate  a sophisticated  repair 
strategy  that  combines  some  of  the  aspects  of  the  strategies  modeled  in  the 
simulation  experiments.  The  network  growth  time  predicted  by  the 
performance  model  will  be  compared  to  the  small-scale  system  results 
allowing  for  improvements  due  to  the  more  sophisticated  strategy. 

Fault-Tolerant  Processor  Faults.  The  recovery  time  from  FTP  faults  is 
measured  from  fault  insertion  to  reconfiguration  completion.  Rapid 
reconfiguration  is  important  for  two  reasons.  First,  an  FTP  is  vulnerable 
to  a nearly  coincident  fault  on  another  channel  during  an  FTP  channel 
failure-recovery  period.  In  this  situation,  a failure  that  would  otherwise 
result  in  a fully  operational  system  leads  to  system  failure.  This  special 
vulnerability  to  subsequent  faults  disappears  after  reconfiguration. 
Second,  certain  pathological  channel  failures  can  cause  erroneous  data  to 
be  sent  over  a network.  In  the  IAPSA  II  design,  the  result  is  that  all 
actuators  will  "freeze"  near  the  last  commanded  position.  It  is  therefore 
important  for  the  FDIR  to  disable  a faulty  channel's  outputs  as  soon  as 
possible.  A small  set  of  FTP  failures  will  be  used  to  exercise  this 
process. 

6.1.3  Application  Timing  Characteristics  - Normal  Conditions 

The  key  application  timing  requirements  will  be  assessed  using  the 
small-scale  system  executing  the  application  workload  simulation.  The 
three  normal  measurement  categories  are  execution  variability,  time  delay, 
and  deadline  margin. 
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Execution  Variability.  These  execution  variability  measurements 

characterize  the  frame- to-frame  regularity  of  key  computing  and  I/O 
activity  events.  This  will  permit  evaluation  of  the  regular  timing 
performance  of  the  system  scheduling  and  dispatch  functions  and  the  I/O 
system  services  processes. 

Time  Delay.  Time  delay  measurements  characterize  the  key  application 
end-to-end  timing  performance.  The  performance  of  each  major  application 
function  is  affected  by  the  overall  time  delay  involved  in  one  control 
cycle.  Times  representative  of  the  sensor  read  and  actuator  write  events 
at  the  device  interface  unit  (DIU)  will  be  recorded  for  each  of  the 
different  application  rate  groups. 

Deadline  Margin.  The  deadline  margin  data  indicate  how  well  the  system  is 
keeping  up  with  the  periodic  demands  of  the  different  application  rate 
groups.  The  deadline  is  the  latest  time  that  the  activity  in  one  control 
cycle  can  complete  and  still  satisfy  the  control  cycle  timing  requirement. 
The  time  from  the  end  of  control  cycle  activity  in  one  frame  to  the  start 
of  control  cycle  activity  in  the  next  frame  marking  the  deadline  will  be 
measured. 

6.1.4  Application  Timing  Characteristics  - Input/Output  Network  Fault 
Conditions 

The  application  timing  measurements  previously  described  will  be  made  in 
the  simulated  failure  experiments  to  see  if  the  additional  demands  made  on 
the  system  due  to  fault  recovery  adversely  affect  the  continued  application 
execution.  The  I/O  network  faults  to  be  simulated  in  this  testing  are 
defined  in  section  6.4.  The  number  of  control  cycles  that  the  application 
processes  must  operate  without  access  to  the  full  complement  of  sensors  and 
actuators  will  be  recorded.  Each  application  frame  without  full  data  due 
to  repair  actions  will  be  marked. 

Transaction  Selection  (Optional).  This  significant  action  eliminates  any 
vulnerability  to  the  temporary  exhaustion  system  failure  condition. 
Temporary  exhaustion  described  in  section  3 was  the  critical  failure 
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condition  for  the  reference  configuration.  The  refined  configuration 
strategy  for  dealing  with  this  threat  requires  the  application  to  first 
determine  that  this  special  action  is  needed.  Next,  the  application  must 
make  the  appropriate  transaction  select  and  transaction  deselect  system 
calls  to  eliminate  the  vulnerability.  The  time  from  the  simulated  fault 
until  execution  of  the  reconfigured  chain  is  the  important  parameter  in 
this  action. 

6.1.5  Application  Timing  Characteristics  - Fault-Tolerant  Processor 
Fault  Conditions 

The  application  timing  measurements  described  in  section  6.1.3  will  be  made 
in  the  simulated  failure  experiments  to  see  if  the  demands  made  on  the 
system  to  handle  faults  adversely  affect  the  continued  application 
execution.  In  addition,  the  system  is  vulnerable  if  a faulty  channel  can 
send  incorrect  output  commands  over  an  I/O  network.  This  measurement  will 
determine  how  long  it  takes  the  system  to  disable  a faulty  channel's 
outputs.  This  will  verify  a key  assumption  that  a bad  channel  is  disabled 
and  communication  responsibility  is  transferred  to  a good  channel  within  a 
few  application  cycles. 

6.2  Experiment  Descriptions 

This  section  contains  general  descriptions  of  the  small-scale  system 
experiments.  It  should  be  noted  that  the  experiment  numbering  begins  with 
10  to  differentiate  from  the  DENET  experiments.  Two  different  application 
organization  options  will  be  used  in  the  testing;  on-demand  I/O  and 
periodic  I/O.  These  options  refer  to  how  the  application  control  cycle  is 
scheduled  and  organized.  The  periodic  option  starts  the  I/O  requests  each 
period  using  the  10  service  timing  function  in  the  I0P.  The  application 
computing  executes  when  the  I/O  request  completion  is  signalled. 


The  on-demand  option  starts  the  application  computing  cycles  using  the 
system  services  timing  function  in  the  CP.  Input/output  requests  are 
executed  when  explicitly  directed  at  the  completion  of  the  application 
computing  activity.  It  should  be  noted  that  this  organization  is  different 
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from  the  on-deraand  option  modeled  in  the  simulation  because  the  I/O 
activity  occurs  at  the  end  of  the  computing  instead  of  at  the  beginning. 
Additionally,  there  is  only  one  cross  processor  (IOP  - CP)  event  per 
control  cycle  instead  of  the  two  in  the  simulation  model  version.  The 
simulation  version  effectively  minimized  the  I/O  activity  jitter  at  the 
expense  of  additional  overhead  processing. 

Experiment  10:  Fault-Tolerant  Processor  Execution  Environment 

Characterization.  A special  version  of  the  pseudoapplication  program  will 
be  run  in  a controlled  environment  to  measure  the  time  required  by  some  key 
operations.  A single  application  task  will  be  executing  in  the  FTP  with  no 
I/O  activity.  The  key  process  to  be  timed  will  be  executed  a large  number 
of  times.  Processes  to  be  measured  in  this  experiment  include  (1)  the  read 
and  assign  real-time  clock  value,  (2)  the  background  self-test  FDIR,  and 
(3)  the  application  workload  loop.  The  first  measurement  will  characterize 
the  overall  impact  of  making  timing  measurements  from  the  psuedoapplication 
program.  The  second  set  of  measurements  will  enable  an  assessment  of  the 
effectiveness  of  the  background  FDIR  process.  This  is  because  the 
effectiveness  is  dependent  on  how  often  it  executes.  The  final  set  of 
measurements  are  needed  to  tailor  the  timing  needs  of  the  psuedoapplication 
so  that  the  desired  timing  load  can  be  simulated  in  the  small-scale  system. 

Experiment  11:  System  Overhead  Characterization.  A special  version  of  the 
pseudoapplication  program  will  be  used  to  time  the  end-to-end  system 
overhead  requirements.  The  total  overhead  for  each  application  rate  group 
will  be  stimulated  in  a controlled  execution  environment.  A special  test 
executive  will  control  the  execution  of  each  application  rate  group 
activity  to  produce  a sequence  identical  to  that  of  an  ideal  major  frame 
resulting  from  an  on-demand  scenario. 

The  special  executive  will  wait  for  the  I/O  request  completion  flag  to 
measure  the  time  needed  to  complete  the  I/O  activity  before  scheduling  the 
next  rate  group.  The  experiment  will  be  run  for  a large  number  of  major 
frames  to  ensure  adequate  overhead  assessment.  The  test  will  be  run  with 
and  without  error  checking  of  each  application  transaction  to  determine  the 
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limits  of  its  effect.  The  sequence  will  be  run  with  and  without  the 
time-critical  FDIR  process  to  measure  the  additional  overhead. 

Experiment  C/P  IOP  FDIR  Phasing  Investigation.  In  this  experiment,  a 
limited  set  of  computational  processor  (CP)  and  I/O  processor  (IOP)  FDIR 
phasing  combinations  will  be  run  to  assess  the  effect  on  key  application 
timing  parameters.  The  set  of  combinations  will  be  run  for  each 
application  scheduling  option.  This  will  be  an  all-up  run  with  full 
operation  of  all  system  service  processes  and  pseudoapplication  processes 
except  for  the  background  FDIR  self-test.  Cyclic  execution  of  application 
rate  groups  will  be  controlled  by  the  defined  system  timing  functions.  The 
computing  workload  and  the  application  group  execution  rates  will  be 
adjusted  to  produce  a slow-time  scenario  for  this  test. 

Experiment  13:  Input/Output  Network  Faults.  In  this  experiment,  link 
faults  will  be  inserted  to  simulate  certain  network  element  faults.  After 
a few  major  frames  of  normal  operation,  a fault  will  be  inserted  at  the 
desired  network  location  at  a predefined  point  in  the  test.  Traffic  on  the 
good  network  and  the  faulty  network  will  be  monitored  to  evaluate  the 
effect  of  the  network  repair  activity.  The  FTP  system  services  logs  will 
be  consulted  to  correlate  the  time  of  failure  detection  and  return  of  the 
network  to  service.  A passive  failure  mode  and  a special  active  failure 
mode  will  be  simulated  for  both  links  and  network  nodes. 

Experiment  14:  Fault-Tolerant  Processor  Faults.  At  a predefined  point  in 
the  test,  the  pseudoapplication  program  will  perform  special  operations  to 
cause  faulty  behavior  in  one  FTP  channel.  Faults  that  result  in  output 
miscompares  and  faults  that  cause  a channel  to  lose  synchronization  will  be 
simulated.  Network  traffic  and  pseudoapplication  task  timing  will  be 
monitored  for  anomalous  behavior  during  the  failure  recovery.  Faults  will 
be  simulated  in  a channel  driving  a network  and  in  a channel  not  driving  a 
network.  The  system  services  logs  will  be  consulted  to  correlate  the  time 
of  failure  detection  and  recovery  to  duplex  operation.  Power  failure 
faults  for  a channel  will  be  simulated  using  hardware  methods  and  will  be 
accomplished  in  a manner  similar  to  the  I/O  network  faults. 
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Experiment  15:  Transaction  Selection  (Optional).  This  experiment  will 

simulate  a transaction  selection  scenario.  It  will  cover  the  end-to-end 
application  process  from  detection  of  the  problem  to  reconfiguration  of  the 
application  chains.  A special  version  of  the  psuedoapplication  program 
will  contain  code  for  the  communications  check  and  the  fault-reaction 
process  that  selects  and  deselects  transactions.  This  experiment  will  also 
use  special  chain  definitions  with  an  additional  transaction  that  will  be 
initially  deselected.  A fault  will  be  simulated  in  the  appropriate  DIU 
link  and  the  time  of  first  execution  of  the  reconfigured  chains  noted. 
After  reconfiguration,  the  chains  on  one  network  will  execute  with  one  less 
transaction  due  to  deselection,  while  the  chains  on  the  other  network  will 
run  one  extra  transaction  due  to  selection. 

The  detailed  experiment  needs  will  be  defined  in  detailed  test  plans  (DTP) 
before  running  any  experiments.  These  DTPs  will  guide  the  actual  execution 
of  the  experiments  on  the  test  facility.  The  DTP  must  describe  the  test 
sequence  of  events,  the  data  configuration  for  the  experiment,  and  the 
schedule  for  data  acquisition  by  the  test  facility.  Data  acquisition 
includes  the  identification  of  parameters  to  be  monitored  and  the 

applicable  frequency  and  simulation  time  spans  for  data  collection. 

6.3  Experiment  Test  Configurations 

The  test  configuration  for  the  small-scale  system  experiments  is  shown  in 
figure  6.3-1.  This  section  describes  the  hardware  and  software  elements  of 
the  test  configuration  organized  into  two  categories,  the  system  under  test 
(SUT)  and  the  test  facility.  The  system-under- test  elements  represent 
components  that  ultimately  are  part  of  the  flight  system.  Test  facility 
elements  are  the  hardware  and  software  elements  that  enable  the  SUT 

operation  to  be  simulated  in  the  laboratory  and  that  provide  the 

development  and  analysis  capabilities  necessary  to  support  testing. 

6.3.1  System  Under  Test  Elements 

Fault-Tolerant  Processor.  The  FTP  is  an  AIPS  triplex  general  purpose 

computer  (GPC).  The  FTP  version  used  in  the  small-scale  system  testing 
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uses  two  Motorola  68010  microprocessors  running  at  8 MHz.  One  is  used  as 
an  I0P  while  the  other  is  used  as  a CP.  The  CP  is  primarily  used  for 
application  software  execution.  Each  FTP  channel  has  a shared  bus,  a data 
exchange  interface,  an  interstage,  and  I/O  network  interface  hardware. 
Operation  of  the  FTP  during  experiment  activities  is  controlled  via  the  FTP 
test  port  that  interfaces  with  the  KcroVAX  experiment  host. 

Fault-Tolerant  Processor  Operational  Test  Program.  The  fault-tolerant 
processor  test  program  (FTPOTP)  consists  of  two  major  elements,  the 
pseudoapplication  software  and  the  AIPS  system  software.  The 
pseudoapplication  software  has  the  responsibility  for  providing  a 
computational  and  I/O  activity  workload  simulation,  collecting  data  in  the 
FTP  execution  environment,  and  implementing  the  FTP  test  control  function 
during  the  experiment  runs.  The  system  services  building  block  elements 
are  linked  with  the  pseudoapplication  elements  to  form  the  loadable  FTPOTP. 

Advanced  Information  Processing  System  Input/Output  Network.  Two  advanced 
information  processing  system  (AIPS)  serial  I/O  networks  are  used  to 
provide  communications  between  an  FTP  and  the  sensors  and  actuators.  The 
network  is  composed  of  prototype  reconfigurable  nodes  and  pairs  of  data 
links  that  support  full  duplex  communications.  The  communications  elements 
uses  a modified  HDLC  protocol.  The  small  scale  system  is  configured  to 
model  the  flight  control  group  of  the  IAPSA  II  reference  configuration. 
Network  1 is  fully  configured  with  all  the  nodes  and  simulated  DIUs  that 
would  be  used  in  the  reference  flight  control  configuration.  All  I/O 
network  faults  will  be  simulated  on  Network  1.  Network  2 is  simulated  with 
two  nodes  interfacing  with  a full  complement  of  DIU  simulators.  During 
operation,  it  behaves  just  like  a fully  configured  network  supporting  the 

full  I/O  traffic  load. 

6.3.2  Test  Facility  Elements 

The  test  facility  must  be  able  to  establish  the  test  conditions  in  the 
system-under- test  elements  to  provide  a representative  I/O  environment  to 
the  small-scale  system  during  experiment  runs  and  to  collect  experiment 
data  from  the  system  during  the  tests.  In  addition  to  these  runtime 
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activities,  the  test  facility  must  support  downloading  of  software  into  the 
system  under  test,  debugging  of  the  experimental  setup,  and  analysis  of  the 
experimental  data. 

Simulation  Host.  The  simulation  host  is  a VMEbus-based  system  containing  a 
16.7  MHz  68020  CPU  (referred  to  as  the  VME  simulation  computer),  16  MB  of 
RAM  for  data  storage,  several  intelligent  serial  I/O  interface  boards 
(referred  to  as  VME  DIU  simulators),  custom  I/O  network  interface  boards,  a 
parallel  I/O  interface  board  for  communications,  and  a fault  insertion 
panel.  During  experiment  runs,  the  simulation  host  is  responsible  for:  (1) 
maintaining  an  experiment  time  reference,  (2)  providing  a real-time  DIU 
simulation  capability,  (3)  controlling  I/O  network  fault  injection 
hardware,  and  (A)  collecting  data  from  I/O  network  activity. 

VME  Operational  Test  Program.  A VME  operational  test  program  (VMVOTP) 
running  on  the  VME  simulation  computer  handles  the  test  setup, 
initialization,  test  control,  and  runtime  data  collection  functions  for  the 
simulation  host.  The  VMEOTP  fault  control  function  commands  the  state  of 
the  I/O  network  fault  insertion  panel  during  experiment  runs  in  accordance 
with  a predefined  fault  script.  This  capability  allows  a wide  range  of 
network  faults  to  be  simulated.  In  cooperation  with  the  DIU  simulators,  it 
manages  the  temporary  storage  of  the  I/O  network  activity  data  collected 
during  experiment  runs.  Finally,  in  its  test  control  function  role,  it 
coordinates  the  start  of  the  experiment  run  with  the  FTP  and  the  orderly 
termination  of  the  experiment  with  the  other  simulation  host  elements. 

Device  Interface  Unit  Simulator  Operational  Test  Program.  In  an  actual 
system,  DIUs  connected  to  the  I/O  network  provide  an  interface  between 
application  software  executing  in  an  FTP  and  the  aircraft  sensors  and 
actuators.  The  small-scale  system  uses  DIU  simulators  to  support  the  I/O 
network  transaction  load  representative  of  an  actual  system.  The 
transactions  contain  dummy  data  used  for  test  purposes  and  do  not  have 
values  representative  of  actual  sensors  or  actuators.  The  DIU  simulator 
operational  test  program  (DIUOTP)  s responsible  for  initializing  the  DIU 
simulator  hardware,  checking  the  command  frames  received,  collecting  d%ta 
about  each  command  frame,  generating  any  necessary  response  frames,  and 
starting  and  stopping  DIU  operation  during  experiments. 


MicroVAX  Experiment  Host.  The  MicroVAX  experiment  host  computer  controls 
the  FTP  using  the  VAX  resident  FTP  interface  program  (VRIP)  and  the  FTP 
resident  AIPSDEBUG  program.  During  experiment  operations,  the  experiment 
host  is  responsible  for  (1)  download  of  the  FTP  operational  test  program 
before  experiment  runs,  (2)  setup  of  the  run  peculiar  data  configuration  in 
the  FTP  before  experiment  runs,  and  (3)  start  of  the  experiment  run.  The 
experiment  host  is  also  responsible  for  upload  and  temporary  storage  of  the 
raw  data  collected  in  the  simulation  host  and  the  FTP  after  experiment  run 
termination. 

The  experiment  host  is  also  used  to  develop,  compile,  and  link  the  FTP 
operational  test  program.  The  host  contains  the  AIPS  system  services 
software  library.  When  the  pseudoapplication  software  is  ready,  this 
machine  compiles  and  links  the  loadable  FTP  operational  test  program.  The 
microvax  experiment  host  converts  the  raw  experiment  data  from  the  VME 
simulation  host  and  the  FTP  to  a common  data  analysis  format.  It  supports 
data  analysis  and  the  archiving  of  processed  experiment  data.  The  MicroVAX 
II  stores  the  VMEOTP  and  the  DIUOTPs  and  downloads  them  to  the  VME 
simulation  computer  and  the  VME  DIU  simulators  before  running  the 
experiments. 

VAXstation  Development  Host.  The  VAXstation  2000  is  used  to  develop  the 
software  and  firmware  targeted  for  the  VME  simulation  host  elements.  This 
includes  the  VMEOTP  and  the  DIUOTPS.  The  software  elements  are  transferred 
to  the  experiment  host  for  downloading  into  the  simulation  computer. 


Laboratory  Communication  Links  (Non-Runtime) 

An  Ethernet  link  provides  a connection  between  the  MicroVAX  experiment  host 
and  the  VAXstation  development  host.  The  link  will  be  used  to  transfer 
developed  VME  operational  test  programs  during  software  development. 


A custom  link  is  used  to  connect  the  FTP  test  port  and  the  test  port 
controller  in  the  MicroVAX  experiment  host.  This  link  is  used  to  download 
the  FTP  operational  test  program  before  experiment  runs,  to  start  the 
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operational  test  program  in  the  FTP,  and  to  upload  raw  experiment  data 
after  experiment  runs. 

A custom  parallel  interface  connects  the  experiment  host  and  the  simulation 
host.  It  is  used  to  download  programs  to  the  simulation  host  and  to  upload 
raw  data  after  experiment  runs. 

Test  Control  Links.  Three  discrete  links  connect  the  FTP  and  the 
simulation  host.  Two  links  are  used  to  coordinate  the  two  main  simulation 
elements  at  the  start  of  the  experiment  run.  The  links  also  allow  the  time 
references  in  the  simulation  host  to  be  synchronized  at  the  start  of  the 
experiment  in  the  FTP.  A test  clock  link  is  used  to  distribute  a common 
time  reference  between  the  FTP  and  the  simulation  host  elements. 

Experiment  Peculiar  Configurations.  Most  of  the  significant  differences 
between  the  element  configurations  used  for  each  experiment  are  in  the 
operational  test  programs  in  the  FTP  and  the  VMEbus  simulation  computer. 
These  differences  are  due  to  the  different  fault  simulation  needs,  data 
collection  needs,  and  simulated  computing  workload  needs  between  the 
experiments.  An  exception  is  that  only  the  FTP  and  the  MicroVAX  experiment 
host  hardware  elements  are  needed  in  experiment  10.  The  hardware 
configuration  for  the  rest  of  the  experiments  is  very  similar. 

6.4  Fault  Insertion 

The  performance  measurement  under  fault  conditions  is  a key  part  of  the 
small-scale  system  testing.  Active  and  passive  failures  will  be  simulated 
in  the  following  I/O  network  elements:  (1)  network  links,  (2)  network 
nodes,  (3)  root  links,  and  (4)  DIU  links.  Passive  faults  will  be  simulated 
by  a stuck  logic  0 signal  on  the  links  while  active  faults  will  be 
simulated  by  a stuck  logic  1 signal  on  the  link.  A node  failure  will  be 
simulated  by  inserting  the  respective  fault  on  all  active  node  links 
simultaneously.  Faults  will  also  be  simulated  on  the  FTP.  Special  code  in 
the  FTPOTP  will  be  used  to  force  a CP  channel  out  of  sync  or  an  I0P  channel 
out  of  sync.  Another  version  will  be  used  to  cause  CP  channel  output 
disagreement . A final  FTP  channel  failure  will  be  loss  of  channel  power. 
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6.4.1  General 


The  key  elements  involved  in  fault  insertion  are  the  I/O  network  link  fault 
insertion  panel,  the  VME  operational  test  program,  and  the  FTP  operational 
test  program.  Patch  cables  to  the  I/O  network  link  fault  insertion  panel 
provide  the  capability  of  inserting  stuck  logic  0 or  stuck  logic  1 signals 
into  an  I/O  network  link.  The  simulation  host  controls  the  introduction  of 
I/O  network  faults  via  the  I/O  network  fault  insertion  panel.  The  VME 
operational  test  program  commands  the  fault  insertion  panel  to  initiate  or 
terminate  fault  behavior. 

FTP  fault  behavior  is  simulated  in  the  FTP  under  control  of  the  FTP 
operational  test  program.  At  the  appropriate  time  in  an  experiment, 
special  failure  simulation  code  is  used  to  cause  the  appropriate  fault 
reaction  from  the  AIPS  FDIR  process. 

6.4.2  Experiment-Peculiar  Strategy 

Input/Output  Network  Faults.  To  set  up  an  experiment  13  run,  the  specific 
links  to  be  failed  must  be  physically  routed  through  the  I/O  network  fault 
insertion  panel  hardware.  The  test  system  hardware  and  software  must  be 
set  up  in  accordance  with  the  fault  script  defined  in  the  detailed  test 
plan.  This  fault  script  defines  the  specific  fault  occurrence  time,  fault 
type,  and  fault  insertion  channel  configuration  used  for  the  test. 

Before  an  experiment  13  run,  a fault  setup  subprogram  running  on  the  VME 
CPU  in  the  simulation  host  sets  up  the  fault  insertion  hardware.  At  the 
appropriate  time  during  the  experiment  start,  the  fault  insertion 
subprogram  sends  the  appropriate  control  word  to  the  I/O  network  fault 
insertion  panel  hardware.  At  the  conclusion  of  the  experiment  run,  the 
fault  insertion  panel  is  reset  to  its  unfaulted  state. 

Fault-Tolerant  Processor  Faults.  To  set  up  most  experiment  14  runs,  a 
specific  fault  scenario  must  be  defined  to  the  FTP  operational  test  program 
as  defined  in  the  fault  script.  The  pseudoapplication  program  will 
incorporate  a high  priority  one-shot  task  (higher  than  all  tasks  except 
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FDIR)  that  wiH  be  scheduled  to  execute  at  the  defined  fault  occurrence 
time.  The  fault  control  task  will  execute  special  code  designed  to  cause 
the  specific  fault  behavior  to  occur.  This  method  will  be  used  for  the 
loss  of  synchronization  and  output  disagreement  faults.  The  power  fail 
fault  will  be  accomplished  using  special  hardware  connected  to  the  fault 
insertion  panel.  Power  fail  simulations  will  be  setup  and  controlled  in  a 
similar  manner  to  the  I/O  network  faults  previously  described. 

6*5  Test  Control  Strategy 

The  experiment  run  is  coordinated  via  two  test  control  discretes  used  to 
synchronize  the  experiment  in  the  FTP  and  the  simulation  host.  While 
either  machine  is  being  set  up  for  a run,  the  sync  discretes  are  set  to  the 
STOP  state.  When  the  simulation  host  has  been  set  up  for  an  experiment  and 
the  run  time  software  has  been  started,  the  VME  sync  discrete  is  set  to  the 
RUN  state.  The  simulation  host  then  waits  for  the  FTP  test  control 
discrete  to  change  to  the  RUN  state. 

When  all  associated  equipment  is  ready  for  experiment  operation,  the  FTP 
operational  test  program  is  started  via  the  VRIP  interface.  On  completion 
of  initialization,  the  FTP  samples  the  VME  sync  discrete.  If  the  input 
line  is  in  the  RUN  state,  the  test  control  function  in  the  FTPOTP  schedules 
the  application  tasks  and  starts  cyclic  operation.  At  the  appropriate 
time,  it  changes  the  FTP  sync  discrete  to  the  RUN  state. 

All  time  reference  clocks  in  the  simulation  host  begin  counting  when  the 
FTP  sync  discrete  goes  to  the  RUN  state.  On  completion  of  an  experiment 
run,  the  FTP  sets  the  FTP  sync  discrete  to  STOP.  The  simulation  host 
responds  by  terminating  data  collection,  recording  experiment  ending  time 
and  changing  the  state  of  the  VME  sync  discrete  to  STOP.  Both  computers 

are  then  free  to  transfer  experiment  raw  data  and  set  up  for  the  next 
experiment . 

The  real-time  clock  in  the  FTP,  the  VME  simulation  computer  time  reference 
clock,  and  the  VME  DIU  simulator  time-reference  clocks  are  synchronized  at 
the  start  of  an  experiment.  A common  test  clock  with  a 4.125  microsecond 
period  drives  all  of  the  time  reference  elements  in  the  system. 
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6.6 


Data  Collection  and  Analysis 


The  DIU  simulator  collects  data  about  the  I/O  network  transactions  in  real 
time.  The  raw  data  consists  of  information  about  all  command  frames  sent 
by  the  FTP  and  processed  by  each  DIU  simulator.  The  information  includes 
command  frame  error  status  information  such  as  HDLC  error,  sumcheck  error, 
etc.  In  addition  to  the  error  status  information,  the  collected 
information  includes  an  identifier,  transmitted  frame  count,  and  the  time 
of  DIU  simulator  processing. 

Data  regarding  FTP  operation  are  collected  during  experiment  runs  by  the 
pseudoapplication  program  and  stored  in  CP  and  IOP  local  memory.  After  run 
completion,  data  are  extracted  from  the  FTP  using  the  FTP  test  port 
interface  and  VRIP/AIPSDEBUG  software  and  stored  in  raw  data  files  on  the 
MicroVAX  experiment  host.  Data  collected  by  the  pseudoapplication  includes 
the  real  time  clock  value  at  significant  application  events,  indicators  for 
certain  I/O  system  and  FTP  errors,  and  the  background  program  workload 
count  at  the  beginning  of  each  minor  frame. 


In  addition  to  the  data  visible  to  the  pseudoapplication,  system  services 
data  are  necessary  to  fully  document  some  experiment  runs.  This 
information  is  recorded  by  system  services  in  special  logs  that  can  be 
accessed  via  CRTs  connected  directly  to  the  FTP  coprocessors.  The 
significant  data  from  these  logs  are  manually  recorded  in  the  experiment 
log  after  each  experiment  run. 

The  raw  data  generated  after  each  experiment  run  will  be  transferred  to  the 
MicroVAX  experiment  host  for  analysis.  The  raw  data  is  converted  to  a 
common  format  before  use  by  the  data  analysis  program.  The  FTP  data 
recorded  in  the  experiment  log  is  entered  manually  for  use  by  the  data 

analysis  program. 

6.6.1  Standard  Statistical  Data 

The  data  analysis  program  has  a statistics  package  that  generates  a 
standard  set  of  statistics  for  certain  data  sets.  The  standard  set  of 
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statistics  includes  the  mean,  the  standard  deviation,  and  the  extreme 
values  found  in  the  data  set.  The  package  also  creates  a histogram  to 
display  the  data  set  values.  The  histogram  range  and  number  of  intervals  is 
set  by  default  based  on  the  extreme  values  in  the  data  set  and  the  number 
of  data  samples.  The  user  can  also  manually  set  the  histogram  display 
parameters. 

For  all  of  the  following  statistical  data  requirements,  the  number  of  data 
points  included  in  the  statistical  summary  will  be  listed.  Data  samples 
associated  with  any  abnormal  frames  are  not  included  in  the  statistical 
summary.  These  abnormal  frame  conditions  are  defined  in  the  event  summary 
description. 

Execution  Variability  Data.  The  statistical  data  in  this  category 
indicates  the  frame- to- frame  variability  of  the  application  execution. 
Execution  variability  statistics  are  based  on  the  frame  relative  time  of  a 
specific  application  event.  The  frame  relative  time  of  each  occurrence  of 
the  event  is  based  on  the  ideal  frame  start  time  for  each  application 
frame.  This  is  determined  based  on  the  ideal  start  time  of  the  very  first 
frame  and  the  frame  repetition  period. 

Duration  Data.  Statistics  in  this  category  are  produced  on  data  derived 
from  the  raw  application  event  information.  The  data  are  based  on  the 
difference  in  time  of  occurrence  between  two  application  events.  Two 
examples  are  time  delay  and  deadline  margin. 

Time  delay  data  are  indicative  of  the  sensor-to-actuator  time  delay  for 
each  application  update  rate.  A transaction  used  by  a specific  rate  group 
is  used  as  representative  of  the  sensor  read  and  actuator  write  events. 
The  difference  between  the  transaction  time  in  one  frame  and  its  occurrence 
in  the  subsequent  frame  is  recorded  as  the  time  delay  value. 

Standard  statistics  data  are  generated  for  the  time  delay  data  sets.  The 
time  delay  values  for  abnormal  frames,  such  as  missed  I/O  update  or  frame 
overrun  situations,  are  not  used  in  the  subsequent  statistical  analysis. 
Similarly,  if  there  is  an  extraordinary  case  of  long  time  delay  because  of 
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a missing  frame,  the  value  is  not  used.  The  number  of  frames  for  which  no 
time  delay  value  was  recorded  due  to  exceptional  conditions  should  be 
listed  in  the  statistics  output. 

Deadline  margin  data  indicates  how  close  the  system  is  to  not  satisfying 
the  regular  update  requirements  of  the  application  processes.  The 
processed  data  is  derived  based  on  the  time  the  final  activity  completes  in 
one  frame  and  the  deadline  for  that  activity  occurs  in  the  subsequent 
frame.  The  final  activity  and  the  deadline  are  different  depending  on  the 
selected  scheduling  mechanism. 

For  periodic  I/O  configurations,  the  deadline  event  occurs  near  the  start 
of  the  I/O  request  processing  in  the  IOP  when  the  output  data  buffer  is 
accessed.  The  final  activity  in  a control  cycle  is  the  updating  of  the 
output  data  for  the  next  I/O  cycle.  The  final  activity  completes  just 
before  the  end  of  the  application  computing. 

For  on-demand  I/O  configurations,  the  deadline  is  the  reading  of  the  input 
data  from  the  preceding  I/O  cycle.  This  takes  place  just  after  the 
beginning  of  the  the  computing  activity  for  a control  cycle.  The  final 
activity  in  the  frame  is  the  completion  of  the  update  of  the  input  data  by 
the  I/O  request  processing. 

A problem  for  deadline  margin  measurements  in  the  small-scale  system  is 
that  one  of  the  events  cannot  be  recorded  directly  unless  the  system 
services  software  is  instrumented.  This  was  not  done  for  these 
experiments.  Therefore,  another  event  closely  related  to  the  actual 
deadline  or  final  activity  is  used.  This  will  introduce  a bias  in  the 
processed  deadline  margin  values. 

The  statistical  analysis  is  performed  on  the  computed  deadline  margin  data 
sets.  The  deadline  margin  values  for  abnormal  frames  such  as  those  with 
missed  I/O  updates  or  frame  overrun  cases  will  not  be  used  in  the 
subsequent  statistical  analysis.  The  number  of  data  samples  rejected  due 
to  abnormal  frames  will  be  shown  in  the  statistics  output. 
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Time  Reserve.  Time  reserve  data  will  be  produced  for  the  CP.  These  data 
are  indicative  of  the  demand  placed  on  the  system  by  the  application  and 
the  time  critical  system  services  (fast  PDIR).  The  time  reserve 
information  for  experiment  12  characterizes  the  steady-state  demands  on  the 
system.  For  experiments  13  and  14,  the  data  illustrates  any  change  in  the 
demand  on  the  system  during  the  fault  recovery  period. 

The  time  reserve  data  for  one  frame  is  determined  by  subtracting  the 
background  counter  value  in  a frame  from  its  value  in  the  subsequent  frame. 
The  background  count  is  incremented  during  the  idle  or  reserve  time  when 
there  is  no  other  processing  to  be  run.  The  time  reserve  data  sets  will  be 
divided  into  four  groups  corresponding  to  the  specific  minor  frame  of  the 

major  frame  cycle  (A,B,C,  or  D).  Standard  statistics  are  generated  on  each 
group. 

Fault  Recovery.  The  fault  recovery  information  indicates  hov  long  the 
system  takes  to  repair  a fault  for  experiment  13  and  14  runs.  Some  of  the 
raw  data  is  recorded  from  CRT  displays  of  the  system  services  log  and  so 
must  be  manually  entered  for  the  data  analysis  program.  The  fault  recovery 
time  is  based  on  the  fault  occurrence  time  and  a corresponding  recovery 
complete  time  for  each  run.  The  fault  recovery  times  for  all  of  the  runs 

having  the  same  configuration  and  fault  type  form  a data  set  for  which 
statistics  are  generated. 

6.6.2  Event  Summary  Data 

addition  to  statistical  data,  the  analysis  program  determines  and 
presents  event  summary  data  for  the  experiment  run.  The  summary 
information  is  based  on  data  collected  during  each  run  as  well  as  detailed 
information  about  certain  situations  occurring  during  the  runs  being 
evaluated.  The  summary  is  organized  by  run  in  the  case  of  multiple-run 
evaluation,  with  the  events  in  each  run  listed  in  chronological  order. 

When  an  event  is  listed,  associated  data  recorded  with  the  event  are 
presented. 
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The  event  summary  for  each  run  includes  a run  start  entry  and  a run 
termination  entry.  A brief  description  of  the  other  significant  situations 
is  presented  in  the  following  paragraphs. 

An  entry  for  the  FTP  fault  insertion  event  is  included  for  all  experiment 
13  runs.  This  entry  will  show  all  data  associated  with  the  specific  fault 
condition.  Similarly,  there  will  be  an  entry  for  the  VME  fault  insertion 
event  for  all  experiment  14  runs.  All  data  associated  with  the  specific 
fault  condition  will  be  presented. 

Experiment  13  and  14  runs  will  also  contain  entries  for  the  end  fault 
repair  event.  These  entries  will  show  the  time  that  the  system  services 
completed  the  reconfiguration  actions  taken  to  repair  the  fault. 

There  will  be  entries  for  each  application  frame  that  experiences 
communication  errors  during  I/O  activity.  These  errors  include  (1)  chain 
error,  (2)  all  transactions  bad,  (3)  chain  not  complete,  (4)  chain  did  not 
execute,  or  (5)  network  out  of  service.  The  entry  will  show  the  time, 
frame  count,  and  application  rate  group  identifier. 

Any  command  frame  received  at  a DIU  with  errors  will  appear  in  the  summary. 
The  command  fame  identifier,  time,  frame  count,  and  error  code  will  be 
presented. 

The  partial  data  summary  shows  the  number  of  frames  in  which  communications 
with  the  complete  set  of  DIUs  is  interrupted  because  a network  is  out  of 
service.  The  application  partial  data  summary  will  show  for  each  run,  by 
application  rate,  the  number  of  frames  in  which  the  application  used  a 
partial  set  of  sensor  and  actuator  data  because  a network  was  taken  out  of 
service. 

The  abnormal  DIU  data  summary  indicates  when  the  DIU  did  not  receive  the 
expected  periodic  update  from  the  application  process.  This  occurs  when  a 
DIU  command  frame  is  repeated  or  skipped.  For  each  DIU  frame  ID,  the 
number  of  occurrences  of  repeated  command  frames  and  skipped  command  frames 
will  be  reported  for  each  run. 
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Abnormal  Pra.es.  The  abnormal  frame  entries  document  the  occurrence  of  an 
incorrect  application  cycle.  The  three  specific  situations  are  missed  I/O 
update,  computing  overrun,  or  IOR  overrun. 

Missed  I/O  updates  occur  when  the  I/O  activity  part  of  the  control  cycle 
and  the  computing  part  of  the  control  cycle  do  not  keep  up  with  each  other. 
In  this  situation,  the  deadline  for  the  final  activity  in  the  frame  is  not 
met.  In  the  on-demand  I/O  case,  the  10  service  activity  does  not  finish 
updating  the  input  data  buffer  before  the  time  it  is  read  by  the  subsequent 
frame  computing  activity.  In  the  periodic  I/O  case,  the  application 
computing  does  not  complete  updating  the  output  data  buffer  before  the 
subsequent  frame  I/O  request. 

A computing  overrun  refers  to  the  situation  in  which  the  application  CP 
processing  for  one  frame  is  scheduled  to  start  while  the  application 
process  for  the  previous  frame  is  still  active.  The  system  ignores  the  new 
request  in  this  situation. 

An  IOR  overrun  occurs  when  the  I/O  system  is  unable  to  process  a submitted 
I/O  request.  In  this  case,  the  I/O  activity  for  a new  frame  is  scheduled 
to  occur  before  the  I/O  activity  has  completed  for  the  previous  frame. 

Special  system  calls  are  used  to  collect  data  about  the  occurrence  of 
either  type  of  overrun. 

The  analysis  output  data  is  determined  based  on  the  raw  data  from  the 
experiment  runs.  Data  in  the  execution  variability  and  duration  categories 
are  based  on  a subset  of  the  possible  raw  data  produced.  For  experiment 
12,  13,  and  14,  the  analysis  output  data  will  be  based  on  raw  data  from  the 
start  of  the  third  application  major  frame  through  the  end  of  the  run. 
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7.0  CONCLUSIONS 


During  the  detailed  design  effort  for  the  IAPSA  II  contract,  a candidate 
architecture  design  based  on  AIPS  fault-tolerant  system  building  blocks  was 
evaluated  for  its  ability  to  meet  the  demanding  performance  and  reliability 
requirements  of  a flight-critical  system.  As  a result  of  the  preliminary 
evaluations  some  refinements  were  made  to  the  candidate  architecture.  The 
refined  configuration  was  evaluated  for  reliability  and  performance  and  a 
set  of  experiments  defined  for  testing  critical  performance  aspects  with  a 
small-scale  system.  This  modeling  effort  provided  several  important 
results  described  below* 


The  major  result  was  that  several  weaknesses  in  the  candidate  architecture 
became  apparent  as  a result  of  using  the  prevalidation  methodology.  These 
shortcomings  were  not  evident  in  the  initial  performance  and  reliability 
calculations.  This  is  important  because  such  concept  weaknesses  are  often 
not  uncovered  until  late  in  the  system  life  cycle,  for  example  at  hardware 
and  software  integration.  The  IAPSA  II  effort  shows  that  it  is  very 
important  to  perform  detailed  evaluation  of  concepts  based  on 
specifications  before  committing  a project  to  a hardware  and  software  build 

phase. 


The  candidate  architecture  was  unable  to  meet  either  the  reliability  or 
performance  requirements.  Reliability  was  affected  by  uncovered  element 
failures  (a  common  finding  in  critical  systems),  rare  mechanical  failure 
modes,  and  an  interaction  of  preexisting  sensor  failures  with  I/O  network 
repair  activity.  As  a consequence,  there  were  several  two-failure 
situations  that  resulted  in  loss  of  safety,  and  one-failure  situations 
resulting  in  loss  of  full  mission  capability. 


The  performance  simulation  showed  that  part  of  the  candidate  system  was 
overloaded  and  did  not  possess  the  needed  growth  capability.  In  fact,  the 
loading  was  such  that  special  coordination  was  needed  between  the 
application  tasks  and  the  time-critical  system  tasks  to  allow  the 
application  workload  to  complete  in  the  allowable  time.  Alternative 


305 


organizations  of  the  workload  were  evaluated  and  only  the  most  efficient 
could  be  fit  into  the  allowable  timeframe.  However,  even  the  optimum 
organization  had  inadequate  growth  capability » 


Changes  were  made  to  the  candidate  architecture  to  better  balance  the 
workload,  to  improve  the  level  of  failure  protection,  and  to  reduce  the 
number  of  communication  elements.  Although  the  refined  system  was  shown  to 
meet  the  reliability  requirements,  several  concerns  became  evident  during 
the  evaluation.  Our  modeling  approach  was  based  on  separate  models 
reflecting  the  success  of  the  key  system  functions.  Modeling  the 
dependency  of  the  system  functions  on  the  central  elements  such  as 
communication  devices  and  electrical  and  hydraulic  power  distribution  was 
difficult.  It  was  easy  to  miss  the  implications  of  system  interconnection 
alternatives,  especially  when  the  central  elements  also  had  dependency 
relationships.  This  was  very  true  in  the  special  power  connection 

reliability  concerns  associated  with  the  refined  configuration  mesh  network 
option. 

A solution  that  would  make  these  central  dependencies  explicit  in  a 
large-system-level  model  still  seems  unattractive.  A method  is  needed  to 
more  formally  organize  the  combining  of  the  separate  section  model  results. 
The  techniques  used  in  the  refined  configuration  analysis  were  more 
effective  and  easier  to  justify  than  those  used  during  the  candidate 
evaluation.  However,  the  step  of  estimating  error  due  to  model  truncation 
when  a problem  is  split  into  submodels  needs  further  development. 

A sensitivity  study  of  the  susceptibility  of  the  system  to  transient  faults 
pointed  out  an  area  of  concern.  Because  of  the  complex  redundancy 
management  strategies,  the  handling  of  transients  is  always  challenging  for 
flight  critical  systems.  One  problem  is  characterization  of  the  transient 
threat.  Solid  operational  data  on  the  likelihood  and  duration  of  transients 
is  scarce.  In  our  limited  study,  the  major  concern  was  transients  that  can 
cause  a channel  to  go  out  of  synchronization.  Because  of  the  heavy 
application  workload  environment,  there  was  not  enough  time  for  the  system 
to  bring  a channel  back  into  synchronization  and  align  its  memory  with  the 
remaining  "good"  channels.  Therefore  a transient  that  causes  loss  of 
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synchronization  has  the  same  effect  as  a permanent  failure.  If  the 
transient  fault  rate  is  significant  in  operational  circumstances,  then 
these  failures  will  contribute  significantly  to  system  failure. 


There  were  many  situations  in  the  study  in  which  performance  and 
reUa5ility  were  closely  interrelated.  The  above  resynchronization 
situation  is  one  example.  Another  was  the  strategy  to  eliminate 
vulnerability  to  "temporary  exhaustion"  failures.  Due  to  the  heavy 
application  I/O  workload,  strategies  of  sending  sensor  and  actuator  data 
redundantly  over  both  networks  were  impractical. 

The  use  of  a discrete  event  simulation  tool,  like  DENET,  is  new  in  the 
analysis  of  a flight  control  system.  Such  tools  appear  very  promising  for 
determining  critical  performance  requirements,  but  much  application  work  is 
needed  to  define  practical  and  effective  modeling  techniques.  However, 
attempting  to  develop  complex  system  configurations  with  multiple 
processing  sites  and  intensive  I/O  needs  without  using  such  tools  to 
uncover  bottlenecks  seems  foolhardy  based  on  our  experience. 

The  rebalancing  of  application  workload  improved  the  overload  situation 
significantly  compared  to  the  candidate  system.  However,  the  preliminary 
simulation  results  experiments  indicates  that  the  improvement  is  not 
enough.  Using  a simplified  adjustment  for  task  overhead  processing  was 
enough  to  show  that  the  growth  factor  for  the  refined  configuration  is 
below  requirements.  To  make  matters  worse,  the  proof-of-concept  testing 
conducted  before  the  small-scale  system  testing  shows  that  the  real  system 
is  not  operating  anywhere  near  the  hardware  limit.  Because  our  performance 
models  were  based  on  very  efficient  operation,  the  small-scale  system 
testing  is  likely  to  show  that  performance  needs  cannot  be  met  with  the 
current  hardware  and  software  design. 

The  AIPS  building  block  hardware  design  is  much  more  mature  than  the 
software  design;  the  functionality  assigned  to  the  system  services  software 
is  overwhelming.  Validation  of  this  complex  software,  which  includes  some 
nondeterministic  behavior,  will  be  extremely  challenging.  Efficiency 
considerations  have  only  recently  been  addressed  in  the  software 


307 


development  effort.  Early  in  the  IAPSA  II  design,  performance  calculations 
were  based  on  the  original  AIPS  system  performance  goals  as  expressed  in 
the  system  specification.  However,  since  these  goals  were  not  reflected  in 
the  performance  requirements  for  the  AIPS  building  blocks,  a building  block 
redesign  will  probably  be  needed. 

In  our  system  study,  a set  of  redundant  buses  provided  nearly  the  same 
general  reliability  as  the  reconf igurable  I/O  mesh  networks.  Because  of 
the  system  software  complexity  associated  with  the  management  of  the 
reconf igurable  mesh  I/O  networks  and  the  needed  validation  effort,  the  I/O 
mesh  network  would  be  eliminated  from  further  consideration  at  this  time. 
However,  to  meet  the  throughput  needs  of  the  application  functions,  an  IC 
network  between  computing  sites  is  essential.  The  IC  network  has  even  more 
demanding  network  management  requirements  than  the  I/O  networks.  The 
characteristics  of  communications  over  the  IC  network  also  generate  some 
demanding  performance  needs.  These  needs  and  associated  potential  resource 
contention  problems  were  not  evaluated  in  our  study. 
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APPENDIX  A 


SELECTED  ASSIST  MODELS 
IAPSA  II  REFINED  CONFIGURATION 


(***  Forward  Area  Model  - Safety  Criteria  - Network  Option  ***) 
(*  Group  A 

(*  


SPACE 


START 


FWNOD : 

0 . . 4, 

FWREC: 

0.  .2, 

FWDIU: 

0..4, 

PITSTK: 

0 . ..  4 , 

PITREC: 

0 . . 2, 

ROLSTK : 

0..4, 

ROLREC : 

0.  .2, 

YAWPED : 

0..4, 

YAWREC: 

0.  .2/ 

FTP: 

0 . . 4, 

FTPREC: 

0..2, 

ROOT: 

0..4, 

ELMC : 

0..4, 

ONREC: 

0.  .2, 

NFAIL: 

0.  .4) 

(*  FORWARD  NODE 

(*  NETWORK  RECOVERY  INDICATOR  *) 
(*  FORWARD  DIU  STATE  INDICATOR  *) 
(*  PITCH  COMMAND  SENSOR  *) 
(*  PITCH  SENSOR  RECOVERY  INDICATOR  *) 
(*  ROLL  COMMAND  SENSOR  *) 
(*  ROLL  SENSOR  RECOVERY  INDICATOR  *) 
(*  YAW  COMMAND  SENSOR  *) 
(*  YAW  SENSOR  RECOVERY  INDICATOR  *) 
(*  FTP  CHANNEL  STATUS  *) 
(*  FTP  CHANNEL  RECOVERY  IND.  *) 
(*  ROOT  LINK  STATUS  *| 
{*  ELECTRIC  POWER  STATE  *> 
(*  OTHER  NODES  IN  A SINGLE  NETWORK  *) 
(*  NO.  OF  FAILED  ELEMENTS  *) 


( 4,  0,  4,  4,  0,  4,  0,  4,  0,  4, 


0,  4, 


4,  0, 


0 ) ; 


PRUNEIF  NFAIL  > 2; 

DEATHIF  PITREC  + FWREC  + ONREC  > 1 OR  ROLREC  + FWREC  + ONREC  > 1 OR 
YAWREC  + FWREC  + ONREC  > 1 ; 

DEATH IF  PITSTK-PITREC  < 1 OR  ROLSTK-ROLREC  < 1 OR  YAWPED-YAWREC  < 1; 
DEATHIF  FTP  - FTPREC  < 1; 


DEATHIF  FTP  < 2; 


DEATHIF 


ROOT  < 3 AND  ( PITREC  > 0 OR  ROLREC  > 0 OR 
YAWREC  > 0 OR  FWREC  > 0 OR  ONREC  > 0 ) ; 


LIST  = 

2; 

TIME  = 

3.0; 

PRUNE  = 

1.0E-16; 

ECHO  - 

0; 

LAMPOS 

= 10.0E-6; 

lamnod 

= 17.0E-6; 

LAMDIU 

= 15.0E-6; 

POSMEAN 

= 3.0E-4; 

POSSTD 

= 1.0E-4; 

NWMEAN 

= 3.0E-4; 

NWSTD 

= 1.0E-4; 

LAMPS 

= 10.0E-6; 

LAMEL 

= 50.0E-6; 

LAMFTP 

= 200.0E-6; 

LAMROOT 

= 15.0E-6; 

FTPMEAN 

= 5.0E-6; 

(*  POSITION  SENSOR  FAILURE  RATE  *) 

(*  NODE  FAILURE  RATE  - CONDITIONED  *) 

(*  DIU  FAILURE  RATE  - CONDITIONED  *) 

(*  RECOVERY  TIME  MEAN  *) 

(*  RECOVERY  TIME  STD  DEV  *) 

(*  NW  RECOVERY  TIME  MEAN  *) 

(*  NW  RECOVERY  TIME  STD  DEV  *) 

(*  LOCAL  POWER  SUPPLY  RATE  - CONDITIONED  *) 
(*  ELECTRIC  POWER  CENTER  FAILURE  RATE  ) 

(*  FTP  CHANNEL  FAILURE  RATE  ' 

(*  FTP  NETWORK  INTERFACE  FAILURE  RATE  ) 

(*  FTP  RECOVERY  TIME  MEAN  ' 


FTPSTD 


1.0E-6; 


(*  FTP  RECOVERY  TIME  STD  DEV 


LAMON  = 289.0E-6;  (*  OTHER  NODES  ON  SINGLE  NW  FAIL  RATE  *) 


(*  PITCH  COMMAND  SENSOR  FAILURES  AND  RECOVERIES  *) 

IF  PITSTK  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 
AND  FTPREC  = 0 AND  FWREC  = 0 AND  ONREC  = 0 THEN 
IF  NFAIL  = 0 OR  PITSTK  = 2 THEN 

TRANTO  PITSTK  = PITSTK-1,  PITREC=PITREC+1,  NFAIL=NFAIL+1 
BY  P ITSTK*LAMPOS ; 

ELSE 

IF  ROOT  = 2 THEN  {*  SINGLE  NETWORK  SUSCEPTIBILITY  *) 

TRANTO  PITSTK=PITSTK-1,  PITREC=PITREC+1,  NFAIL=NFAIL+1 
BY  (2/3) *LAMPOS; 

TRANTO  PITSTK=PITSTK-1,  NFAIL=NFAIL+1 
BY  ((PITSTK  - 2)  + 4/3  )*LAMPOS; 

ELSE 

TRANTO  PITSTK  = PITSTK-1,  NFAIL=NFAIL+1 
BY  PITSTK* LAMPOS; 

ENDIF; 


ENDIF; 


ELSE  (*  NEARLY  COINCIDENT  SENSOR- NETWORK  *) 

IF  FWREC  >0  (*  SAME  NODE  SET  *) 

TRANTO  PITSTK  ■ PITSTK-1,  PITREC=PITREC+1,  NFAIL=NFAIL+1 
BY  (PITSTK+1) *LAMPOS  /2; 

IF  ONREC  >0  (*  OTHER  NODES  *) 

TRANTO  PITSTK  = PITSTK-1,  PITREC=PITREC+1,  NF AI L=NFAI L+ 1 
BY  PITSTK*LAMPOS  /2; 

IF  PITREC  > 0 THEN  (*  RECOVERY  OR  SYSTEM  LOSS  *) 

TRANTO  PITREC  = 0 BY  < POSMEAN,  POSSTD  >; 

TRANTO  PITSTK  = PITSTK-1,  PITREC=PITREC+1,  NFAIL=NFAIL+1 
BY  PITSTK* LAMPOS ; 

ENDIF; 


ENDIF; 


(*  ROLL  COMMAND  SENSOR  FAILURES  AND  RECOVERIES  *) 

IF  ROLSTK  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 
AND  FTPREC  = 0 AND  FWREC  = 0 AND  ONREC  = 0 THEN 
IF  NFAIL  = 0 OR  ROLSTK  = 2 THEN 

TRANTO  ROLSTK  = ROLSTK-1,  ROLREC=ROLREC+l,  NFA I L=NF A I L + 1 
BY  ROLSTK* LAMPOS; 

ELSE 

IF  ROOT  = 2 THEN 

(*  SINGLE  NETWORK  SUSCEPTIBILITY  *) 

TRANTO  ROLSTK=ROLSTK-l,  ROLREC=ROLREC+l , NFAIL=NFAIL+1 
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BY  (2/3) *LAMPOS; 

TRANTO  RDLSTK-ROLSTK-1,  NFAIL-NFAIL+1 
BY  ( (ROLSTK  - 2)  + 4/3  )*LAMPOS; 

ELSTRANTO  ROLSTK  = ROLSTK- 1,  NFAIL=NFAIL+1 
BY  ROLSTK* LAMPOS; 

ENDIF; 

ENDIF; 

ELSE  (*  NEARLY  COINCIDENT  SENSOR-NETWORK  *) 

rr  furs' r >0  (*  SAME  NODE  SET  *) 

STO  ROLSTK  = ROLSTK-1,  ROLREC-ROLREC+1,  NFAIL-NFAIL+1 

BY  (ROLSTK+1) *LAMPOS  / 2; 

IF  tbantc/rolstk  rS-rROL^c.ROLREC+1, 

BY  ROLSTK*LAMPOS  / 2; 

if  ROLREC  > 0 THEN  (*  RECOVERY  OR  SYSTEM  LOSS  *) 

SKS  S : -"-i,  — — 

BY  ROLSTK* LAMPOS ; 

ENDIF; 


ENDIF; 


(*  YAW  COMMAND  SENSOR  FAILURES  AND  RECOVERIES  ) 


IF  YAWPED  > 0 AND  PITREC  = 0 AND  ROLREC = 0 AND  YAWREC  = 0 
AND  FTPREC  = 0 AND  FWREC  = 0 AND  ONREC  - 0 THEN 

IF  Sto=yaw?edY=WyaSped- JH?awrec=yawrec+i,  NFAIL=NFAIL+1 
BY  YAWPED* LAMPOS; 

ELSE 

IF  ROOT  = 2 THEN 

(*  SINGLE  NETWORK  SUSCEPTIBILITY  ) — nfrtt +1 

TRANTO  YAWPED-YAWPED-1,  YAWREC=YAWREC+1 , NFAIL-NFAIL+1 

BY  (2/3) *LAMPOS; 

TRANTO  YAWPED=YAWPED-1,  NFAIL-NFAIL+1 
BY  ((YAWPED  - 2)  + 4/3  )*LAMPOS; 

ELSTRANTO  YAWPED  = YAWPED -1 ; NFAIL=NFAIL+1 
BY  YAWPED * LAMPOS; 

ENDIF; 

ENDIF; 

ELSE  (*  NEARLY  COINCIDENT  SENSOR-NETWORK  *) 

IF  StoYAWRED  1\a^dTyA^-™>RSC+1,  NFAIL=NFAIL+1 

BY  (YAWPED+1) *LAMPOS  /2; 


IF  ONREC  >0  (*  OTHER  NODES  *) 
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TRANTO  YAWPED  = YAWPED- 1,  YAWREC=YAWREC+1 , NF AI L=NF  A I L + 1 
BY  YAWPED*LAMPOS  /2; 

IF  YAWREC  > 0 THEN  (*  RECOVERY  OR  SYSTEM  LOSS  *) 

TRANTO  YAWREC  = 0 BY  < POSMEAN,  POSSTD  >; 

TRANTO  YAWPED  = YAWPED-1,  YAWREC=YAWREC+1 , NFAIL=NFAIL+1 
BY  YAWPED *LAMPOS; 

ENDIF; 


ENDIF; 


(*  FORWARD  AREA  NODE  FAILURES  *) 

IF  FWNOD  > 0 AND  FWREC  = 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND 
YAWREC  = 0 AND  FTPREC  = 0 AND  ONREC  = 0 THEN 
IF  PITSTK  < 3 OR  ROLSTK  < 3 OR  YAWPED  < 3 THEN 

(*  TEMPORARY  EXHAUSTION  FAILURE  *) 

TRANTO  FWNOD=FWNOD-l,  FWDIU=FWDIU-1,  PITSTK=PITSTK-1 , 

ROLSTK=ROLSTK-l , YAWP E D=YAWP ED - 1 , ROOT=ROOT-l, 

FWREC=2,  NFAIL=NFAIL+1  BY  (2/3) *LAMNOD; 

(*  TEMPORARY  EXHAUSTION  AVOIDED  *) 

TRANTO  FWNOD=FWNOD - 1 , FWDIU=FWDIU-1,  PITSTK=PITSTK-1 
ROLSTK=ROLSTK-l , YAWPED=YAWPED-1 , ROOT=ROOT-l,  ' 

NFAIL=NFAIL+1  BY  ((  FWNOD-2)  + 4/3)*LAMNOD; 

E^SE  (*  NO  TEMPORARY  EXHAUSTION  VULNERABILITY  *) 

IF  ROOT  = 2 THEN  (*  SINGLE  NETWORK  VULNERABILITY  *) 

TRANTO  FWNOD=FWNOD-l,  FWDIU=FWDIU-1,  PITSTK=PITSTK-1 
ROLSTK=ROLSTK-l,  YAWPED= YAWPED-1,  ROOT=ROOT-l, 

FWREC=FWR£C+ 1 , NFAIL=NFAIL+1  BY  (2/3) *LAMNOD; 

TRANTO  FWNOD=FWNOD-l,  FWDIU=FWDIU-1,  PITSTK=PITSTK-1 
ROLSTK=ROLSTK-l , YAWPED=YAWPED-1 , ROOT=ROOT-l, 

NFAIL=NFAIL+1  BY  ((  FWNOD-2)  + 4/3)*LAMNOD; 

ELSE  (*  NO  SINGLE  NETWORK  VULNERABILITY  *) 

IF  ROOT  > (FWNOD+ELMC-4 ) THEN 

(*  CHECK  FOR  TWO  FAULTS  ON  SAME  "CHANNEL"  *) 

TRANTO  FWNOD=FWNOD-1,  FWDIU=FWDIU-1,  PITSTK=PITSTK-1 
ROLSTK=ROLSTK-l , YAWPED= YAWPED-1,  ROOT=ROOT-l, 

NFAIL=NFAIL+1  BY  ROOT*  LAMNOD; 

ELSE 

(*  FAULTS  ARE  ON  SEPARATE  "CHANNELS"  *) 

(*  FORWARD  NODE  FAILURE  AFFECTS  ROOT  LINK  AND  DIU  *) 

IF  NFAIL  = 0 THEN 

TRANTO  FWNOD=FWNOD-l,  FWDIU=FWDIU-1 , PITSTK=PITSTK-1 , 
ROLSTK=ROLSTK-l , YAWPED=YAWPED-1,  ROOT=ROOT-l,  FWREC=FWPFC+1 , 

NFAIL=NFAIL+1  BY  FWNOD*  LAMNOD; 
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TRANTO  FWNOD=FWNOD-l,  FWDIU=FWDIU-1 , PITSTK-PITSTK-1, 
ROLSTK=ROLSTK-l,  YAWPED-YAWPED-1,  ROOT-ROOT-1, 
NFAIL=NFAIL+1  BY  ROOT*  PITSTK*ROLSTK*YAWPED*LAMNOD/ 

( (FWNOD+ELMC-4) * FWDIU**2  ); 

END IF; 

ENDIF ; 

ENDIF; 

ENDIF; 


ELSE 


(*  NEARLY  COINCIDENT  NETWORK-SENSOR  FAILURES  *) 


IF  FWREC  = 1 THEN  (*  SAME  NODE  SET  *) 

(*  NETWORK  RECOVERY  *) 
TRANTO  FWREC  = 0 BY  < NWMEAN,  NWSTD  >; 
ENDIF; 


IF  PITREC  = 1 

TRANTO  FWNOD=FWNOD-l,  FWREC=FWREC+1 , NFAIL-NFAIL+1  BY 
FWNOD  * LAMNOD  / 2; 

IF  ROLREC  — 1 

TRANTO  FWNOD-FWNOD-1,  FWREC=FWREC+1 , NFAIL=NFAIL+1  BY 
FWNOD* LAMNOD  /2; 

IF  YAWREC  = 1 

TRANTO  FWNOD=FWNOD-l,  FWREC-FWREC+1,  NFAIL=NFAIL+1  BY 
FWNOD* LAMNOD  /2; 

ENDIF; 

(*  OTHER  NODE  FAILURES  *) 

IF  FWREC  = 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND 
YAWREC  = 0 AND  FTPREC  = 0 AND  ONREC  = 0 THEN 
IF  PITSTK  < 3 OR  ROLSTK  < 3 OR  YAWPED  < 3 THEN 
(*  TEMPORARY  EXHAUSTION  VULNERABLE  *) 

TRANTO  ONREC=2,  NFAIL=NFAIL+1  BY  LAMON/3; 

ELSE 

IF  ROOT  = 2 THEN  (*  SINGLE  NW  VULNERABLE  *) 


TRANTO  ONREC-1,  NFAIL=NFAIL+1  BY  LAMON/3; 

ELSE 

IF  NFAIL  = 0 TRANTO  ONREC=l,  NFAIL=NFAIL+1  BY 
2*LAMON; 

ENDIF ; 

ENDIF; 

(*  NEARLY  COINCIDENT  FAILURES-  RECOVERIES  *) 

IF  ONREC  = 1 

TRANTO  ONREC  = 0 BY  < NWMEAN,  NWSTD  >; 


IF  PITREC=1  OR  ROLREC=l  OR  YAWREC=1 

TRANTO  ONREC=l,  NFAIL=NFAIL+1  BY  LAMON; 


ENDIF; 


(*  FORWARD  DIU  FAILURES  *) 

IF  FWDIU  > 0 AND  FWREC  = 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND 
YAWREC  = 0 AND  FTPREC  = 0 AND  ONREC  = 0 THEN 

TRANTO  F WD I U=FWD I U- 1 , PITSTK-PITSTK-1,  ROLSTK=ROLSTK- 1 YAWPED= 
YAWPED- 1,  NFAIL=NFAIL+1  BY  PITSTK*ROLSTK*YAWPED* ( LAMDIU  + LAMPS  ) / 
FWDIU* *2 ; 


ENDIF; 


(*  FTP  CHANNEL  FAILURES  *) 

IF  FTP  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 
AND  FWREC  = 0 AND  FTPREC  = 0 AND  ONREC  = 0 THEN 
IF  NFAIL  = 0 THEN 

TRANTO  FTP-FTP-1,  FTPREC-FTPREC+1,  ROOT-ROOT-1,  NFAIL=NFAIL+1 
BY  FTP*LAMFTP; 

ELSE 

TRANTO  FTP-FTP-1,  ROOT-ROOT-1,  NFAIL=NFAIL+1 
BY  ROOT*LAMFTP; 

ENDIF; 

ELSE 

IF  FTPREC  > 0 THEN 

(*  FTP  CHANNEL  RECOVERY  *) 

TRANTO  FTPREC=FTPREC-1  BY  < FTPMEAN,  FTPSTD  >; 

(*  COINCIDENT  FAULT  *) 

TRANTO  FTP-FTP- 1,  FTPREC-FTPREC+1,  ROOT-ROOT-1,  NFAIL-NFAIL+1 
BY  FTP*LAMFTP; 

ENDIF; 


ENDIF; 


(*  NETWORK  INTERFACE  FAILURES  *) 

IF  ROOT  > 2 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 AND  FTPREC  = 0 
AND  FWREC  = 0 AND  ONREC  =0 

TRANTO  ROOT-ROOT-1,  NFAIL-NFAIL+1  BY  ROOT*LAMROOT; 

(***  ELECTRIC  POWER  DISTRIBUTION  FAILURES  ***) 

IF  ELMC  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 AND  FTPREC  = 0 
AND  FWREC  = 0 AND  ONREC  = 0 THEN  U 

(*  ELMC  FAILURE  AFFECTS  DIU,  FTP  AND  ROOT  LINK  *) 

IF  ROOT  > (FWNOD+FTP-4)  THEN 

(*  CHECK  FOR  FAULTS  ON  SAME  "CHANNEL"  *) 

TRANTO  FWDIU-FWDIU-1,  PITSTK-PITSTK-1, 

ROLSTK-ROLSTK- 1 , YAWPED-YAWPED-1 , FTP-FTP-1,  ROOT-ROOT-1 
ELMC-ELMC-1,  ' 


A-6 


NFAIL=NFAIL+1  BY  ROOT*  LAMEL; 


ELSE 

(* 


ENDIF; 

ENDIF; 


FAULTS  ON  DIFFERENT  "CHANNELS"  *) 


TRANTO  FWDIU-FWDIU-1,  PITSTK=PITSTK-1, 
ROLSTK=ROLSTK-l,  YAWPED=YAWPED-1,  FTP=FTP-1, 
ELMC=ELMC-1, 

NFAIL=NFAIL+1  BY  ROOT*  PITSTK*ROLSTK* YAWPED* 
LAMEL  / ( (FWNOD+ELMC-4) * FWDIU**2  ); 


ROOT=ROOT-l, 
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(***  Mid  Area  Model  - Safety  Criteria  - Network  Option  ***) 
(*  Group  A *) 
(*  *) 


SPACE  = ( 


START  = ( 4 


MIDNOD : 

0. 

•4, 

(* 

MID  NODE 

*) 

MIDREC : 

0. 

• 2, 

(* 

NETWORK  RECOVERY  INDICATOR 

*) 

MIDDIU: 

0. 

• 4, 

(* 

MID  DIU  STATE  INDICATOR 

*) 

GYRO: 

0. 

• 8, 

(* 

GYROS 

*) 

GYREC: 

0. 

•2, 

(* 

GYRO  RECOVERY  INDICATOR 

*) 

ACCEL: 

0. 

• 8, 

(* 

ACCELEROMETERS 

*) 

ACCREC: 

0. 

.2, 

(* 

ACCEL  RECOVERY  INDICATOR 

*) 

CNDV: 

0. 

•4, 

(* 

CND  VALVE  STATE 

* 

HYD: 

0. 

• 2, 

(* 

HYDRAULIC  SYSTEM  STATE 

*) 

ELMC: 

0. 

•4, 

(* 

ELECTRIC  SUPPLY  SYSTEM  STATE 

*) 

ONREC: 

0. 

.2, 

(* 

OTHER  NODES  IN  A SINGLE  NETWORK 

*) 

NFAIL: 

0. 

• 4); 

(* 

NO.  OF  FAILED  ELEMENTS 

*) 

0,  4, 

o 

oo 

<30 

O 

4, 

2,  4,  0,  0 ); 

PRUNEIF  NFAIL  > 2; 


DEATH IF  GYREC  + ACCREC  + MIDREC  + ONREC  > 1; 

DEATHIF  GYRO-GYREC  < 3 OR  ACCEL-ACCREC  < 3; 

DEATHIF  CNDV  = 0; 

LIST  = 2; 

TIME  = 3.0; 

PRUNE  = 1.0E-16; 

ECHO  = 0; 


LAMGYRO  = 50.0E-6;  (*  GYRO  FAILURE  RATE  *) 

LAMACC  = 30.0E-6;  (*  ACCELEROMETER  FAILURE  RATE  *) 

LAMNOD  = 17.0E-6;  (*  NODE  FAILURE  RATE  - CONDITIONED  *) 

LAMDIU  = 15.0E-6;  (*  DIU  FAILURE  RATE  - CONDITIONED  *) 

GYRMEAN  = 3.0E-4;  (*  RECOVERY  TIME  MEAN  *) 

GYRSTD  = 1.0E-4;  (*  RECOVERY  TIME  STD  DEV  *) 

ACCMEAN  = 3.0E-4;  (*  ACC  RECOVERY  TIME  MEAN  *) 

ACCSTD  = 1.0E-4;  (*  ACC  RECOVERY  TIME  STD  DEV  *) 

LAMC  = 50.0E-6;  (*  PROCESSOR  FAILURE  RATE  *) 

LAMPOS  = 10.0E-6;  (*  POSITION  SENSOR  FAILURE  RATE  *) 

LAMV  = 15.0E-6;  (*  VALVE  GROUP  FAILURE  RATE  *) 

VJAM  = 3. 3333E-5;  (*  ACTUATOR  JAM  FAILURE  FRACTION  *) 

LAMHYD  = 45.0E-6;  (*  HYDRAULIC  SYSTEM  FAIL  RATE  *) 

LAMPS  = 10.0E-6;  (*  LOCAL  POWER  SUPPLY  - CONDITIONED  *) 

LAMEL  = 50.0E-6;  (*  ELMC  FAILURE  RATE  *) 

NWMEAN  = 3.0E-4;  (*  NW  RECOVERY  TIME  MEAN  *) 

NWSTD  = 1.0E-4;  (*  NW  RECOVERY  TIME  STD  DEV  *) 

LAMON  = 289. 0E- 6;  (*  OTHER  NODES  FAILURE  RATE  *) 
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(*  GYRO  SENSOR  FAILURES  AND  RECOVERIES  *) 

IF  GYRO  > 0 AND  GYREC  = 0 AND  ACCREC  = 0 AND  MIDREC  = 0 AND  ONREC  = 

IF  GYRO  = 4 OR  NFAIL  = 0 THEN  <*  EXHAUSTION  *) 

TRANTO  GYRO  = GYRO-1,  GYREC=GYREC+1 , NFAIL=NFAIL+1 
BY  GYRO*LAMGYRO ; 

ELSE 

TRANTO  GYRO  = GYRO-1,  NFAIL=NFAIL+1 
BY  GYRO*  LAMGYRO ; 

ENDIF; 

ELSE 

<*  GYRO  FAILURE  RECOVERY  *) 

IF  GYREC  = 1 TRANTO  GYREC=0  BY  < GYRMEAN,  GYRSTD  >; 

(*  NCF:  GYRO  - NETWORK  *) 

IF  MIDREC  = 1 OR  ONREC  = 1 ,.i 

TRANTO  GYRO  = GYRO-1,  GYREC=GYREC+1 , NFAIL=NFAIL+1 

BY  GYRO* LAMGYRO/ 2; 

ENDIF; 

(*  ACCEL  SENSOR  FAILURES  AND  RECOVERIES  *) 

IF  ACCEL  > 0 AND  GYREC  = 0 AND  ACCREC  = 0 AND  MIDREC  = 0 AND  ONREC 

IF  ACCEL  = 4 OR  NFAIL  = 0 THEN  (*  EXHAUSTION  *) 

TRANTO  ACCEL  = ACCEL-1,  ACCREC=ACCREC+1,  NFAIL=NFAIL+- 
BY  ACCEL* LAMACC; 

ELSE  , 

TRANTO  ACCEL  = ACCEL- 1,  NFAIL=NFAIL+1 

BY  ACCEL*LAMACC; 

ENDIF; 


ELSE 


(*  ACCELEROMETER  FAILURE  RECOVERY  *)  ^ 

IF  ACCREC  = 1 TRANTO  ACCREC=0  BY  < ACCMEAN,  ACCSTD  >; 

(*  NCF:  ACCEL  - NETWORK  *) 

IF  TRANTO  ACCELR=°ACCEL-l!  ACCREC=ACCREC+1,  NFAIL=NFAIL+1 
BY  ACCEL*LAMACC/2; 


ENDIF; 


(***  VALVE  GROUP  FAILURES  ***) 


IF  CNDV  > 0 AND  GYREC=0  AND 
IF  NFAIL  = 0 

TRANTO  CNDV=0 
TRANTO  CNDV=CNDV-1 , 


ACCREC=0  AND  MIDREC  = 0 AND  ONREC  = 0 

NFAIL=NFAIL+1  BY  CNDV*VJAM*LAMV; 

' NFAIL=NFAIL+1  BY  CNDV* (1 . 0-VJAM) *LAMV; 


ENDIF;  . 


(*  HYDRAULIC  SYSTEM  FAILURES  *) 

HYD  > 0 AND  GYREC=0  AND  ACCREC=0  AND  MIDREC  = 0 AND 
(HYD-NFAIL  >=  0 ) AND  ONREC  = 0 THEN 

TRANTO  CNDV=CNDV-2 , HYD=HYD-1,  NFAIL=NFAIL+1 
BY  CNDV* (CNDV-1) *LAMHYD  / ( 2*  (2*HYD-1)  ); 


0 THEN 


= 0 THEN 


THEN 


IF  (2*HYD-CNDV)  > 0 
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TRANTO  CNDV=CNDV-i,  HYD=HYD-1,  NFAIL=NFAIL+1 
EY  (2*HYD-CNDV) *2 *CNDV*LAMHYD  / ( 2*  (2*HYD-1)  ); 

IF  (2*HYD-CNDV)  > 1 

TRANTO  HYD=HYD-1,  NFAIL=NFAIL+1 

BY  (2*HYD-CNDV) * (2*HYD-CNDV-1) +LAMHYD  / ( 2*  (2*HYD-1)  ); 

ENDIF; 


{*  MID  AREA  NODE  FAILURES  *) 

IF  MIDNOD  > 0 AND  MIDREC  = 0 AND  GYREC  = 0 AND  ACCREC  = 0 AND  ONREC  = 0 THEN 
IF  ( MIDNOD=2  AND  MIDDIU=4  ) OR  ( MIDNOD=3  AND  MIDDIU=3)  THEN 

(*  TEMPORARY  EXHAUSTION  FAILURE  *) 

TRANTO  MIDNOD=MIDNOD-l, 

MIDREC=2,  NFAIL=NFAIL+1  BY  LAMNOD; 

(*  TEMPORARY  EXHAUSTION  AVOIDED  *) 

TRANTO  MIDNOD=MIDNOD-l,- 
NFAIL=NFAIL+1  BY  ( MIDNOD-1  )* LAMNOD; 

ELSE  (*  NO  TEMPORARY  EXHAUSTION  VULNERABILITY  *) 

IF  MIDNOD  = 3 AND  MIDDIU  = 4 THEN 

(*  MID  NODE  FAILURE  MIGHT  AFFECT  DIU  *) 

IF  GYRO  = 8 AND  ACCEL  = 8 THEN 

TRANTO  MIDNOD=MIDNOD-l,  MIDDIU=MIDDIU-2,  GYRO=GYRO-4, 
ACCEL=ACCEL-4 , NFAIL=NFAIL+1 
BY  LAMNOD; 

ELSE 

IF  GYRO  < 8 

TRANTO  MIDNOD=MIDNOD-l,  MIDDIU=MIDDIU-2,  GYRO=GYRO-3 , 
ACCEL=ACCEL-4 , NFAIL=NFAIL+1 
BY  LAMNOD  / 2; 

IF  ACCEL  < 8 

TRANTO  MIDNOD-MIDNOD-1,  MIDDIU=MIDDIU-2,  GYRO=GYRO-4 , 
ACCEL=ACCEL-3,  NFAIL=NFAIL+1 
BY  LAMNOD  / 2; 

TRANTO  MIDNOD=MIDNOD-l,  MIDDIU=MIDDIU-2,  GYRO=GYRO-4, 
ACCEL=ACCEL-4 , NFAIL=NFAIL+1 
BY  LAMNOD  / 2; 

ENDIF; 


TRANTO  MIDNOD=MIDNOD-l,  NFAIL=NFAIL+1  BY  2 * LAMNOD; 

ELSE 

IF  MIDNOD  = 2 AND  ELMC  = 2 THEN 

(*  ELECTRIC  SUPPLY  EXHAUSTION  *) 

TRANTO  MIDNOD=MIDNOD- 1 , MIDDIU=MIDDIU-1,  GYRO=GYRO-2, 
ACCEL=ACCEL-2,  NFAIL=NFAIL+1  BY  MIDNOD*  LAMNOD; 

ELSE 
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(*  MID  NODE  FAILURE  CAN'T  AFFECT  DIU  *) 


IF  NFAIL=0  THEN 

TRANTO  MIDNOD=MIDNOD-l, 
BY  MID  NOD  * LAMNOD ; 

ELSE 

TRANTO  MIDNOD=MIDNOD-l, 
END IF; 

ENDIF; 

ENDIF; 


MIDREC=1,  NFAIL=NFAIL+1 


NFAIL=NFAIL+1  BY  MIDNOD *LAMNOD ; 


ENDIF; 


ELSE 


(*  NEARLY  COINCIDENT  NETWORK-SENSOR  FAILURES  *) 


IF  MIDREC  = 1 

(*  NETWORK  RECOVERY  *) 

TRANTO  MIDREC  = 0 BY  < NWMEAN,  NWSTD  >; 

IF  GYREC  = 1 OR  ACCREC  = 1 

(*  COINCIDENT  FAULT  *) 

TRANTO  MIDNOD=MIDNOD-l,  MIDREC=MIDREC+1 , NFAIL=NFAIL+1  BY 
MID NOD  * LAMNOD  /2; 

ENDIF; 


(**  OTHER  NODE  FAILURES  **) 

IF  MIDREC  = 0 AND  GYREC  = 0 AND  ACCREC  = 0 AND  ONREC  — 0 THEN 

IF  ( MIDNOD=2  AND  MIDDIU=4  ) OR  ( MIDNOD=3  AND  MIDDIU=3)  THEN 
(*  TEMPORARY  EXHAUSTION  VULNERABLE  *) 

TRANTO  ONREC  = 2,  NFAIL=NFAIL+1  BY  LAMON/ 2; 

ELSE 

IF  NFAIL  = 0 TRANTO  ONREC  = 1,  NFAIL=NFAIL+1  BY  2*  LAMON; 


ENDIF; 

ELSE 

IF  ONREC  =1  (*  NW  RECOVERY  *) 

TRANTO  ONREC  = 0 BY  < NWMEAN,  NWSTD  >; 

IF  GYREC  = 1 OR  ACCREC  = 1 

(*  NEARLY  COINCIDENT  FAULTS  SENSOR  - NETWORK  *) 

TRANTO  ONREC=l,  NFAIL=NFAIL+1  BY  LAMON; 

ENDIF; 

(*  MID  DIU  FAILURES  *) 

IF  MIDDIU  > 0 AND  MIDREC  = 0 AND  GYREC  = 0 AND  ACCREC  = 0 AND  ONREC  = 0 
TRANTO  MIDDIU=MIDDIU-1,  GYRO=GYRO-2,  ACCEL=ACCEL-2 , 
NFAIL=NFAIL+1  BY  GYRO*  (GYRO-1)*  ACCEL*  (ACCEL-1)* 

(LAMDIU  + LAMPS)/  ( 2*  (2*MIDDIU)*  (2*MIDDIU-1) **2  ); 

IF  2*MIDDIU  - GYRO  > 0 

TRANTO  MIDDIU=MIDDIU-1,  GYRO=GYRO-l,  ACCEL=ACCEL-2 , 
NFAIL=NFAIL+1  BY  2*GYRO*  (2*MIDDIU-GYRO) * ACCEL*  (ACCEL-1)* 
(LAMDIU  + LAMPS)/  ( 2*  (2*MIDDIU) * (2*MIDDIU-1 ) **2  ); 


THEN 
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IF  2*MIDDIU  - ACCEL  > 0 

TRANTO  MIDDIU=MIDDIU-1 , GYRO=GYRO-2,  ACCEL=ACCEL-1, 
NFAIL=NFAIL+1  BY  GYRO*  (GYRO-1)*  2*ACCEL*  (2*MIDDIU-ACCEL) * 
(LAMDIU  + LAMPS)/  ( 2*  (2*MIDDIU)*  (2*MIDDIU-1) **2  ); 


ENDIF; 


(****  ELECTRICAL  POWER  DISTRIBUTION  FAILURES  ***) 

IF  ELMC  > 2 AND  MIDREC  = 0 AND  GYREC  = 0 AND  ACCREC  = 0 AND  ONREC  = 0 THEN 

IF  ELMC  = 4 AND  NFAIL  < 2 

TRANTO  ELMC=ELMC-1,  NFAIL=NFAIL+1  BY  ELMC*LAMEL; 

IF  ELMC  = 3 THEN 
IF  NFAIL  = 1 

(*  TRANSITION  TO  SINGLE  NW  OPERATION  *) 

TRANTO  MIDNOD=MIDNOD-2,  MIDDIU=MIDDIU-2,  GYRO=GYRO-4, 
ACCEL=ACCEL- 4 , 

ELMC=ELMC-1,  NFAIL=NFAIL+1  BY  LAMEL; 

IF  MIDNOD  = 3 

(*  TRANSITION  TO  ELECTRIC  SOURCE  EXHAUSTION  *) 

TRANTO  MIDNOD=MIDNOD-2,  MIDDIU=MIDDIU-3,  GYRO=GYRO- 6 , 
ACCEL=ACCEL-6, 

ELMC=ELMC-1 , NFAIL=NFAIL+1  BY  LAMEL/ 2; 

IF  MIDDIU  = 3 

(*  TRANSITION  TO  ELECTRIC  SOURCE  EXHAUSTION  *) 

TRANTO  MIDNOD=MIDNOD-2,  MIDDIU=MIDDIU-2,  GYRO=GYRO-4, 
ACCEL=ACCEL-4 , 

ELMC=ELMC-1,  NFAIL=NFAIL+1  BY  LAMEL/2; 


ENDIF; 

ENDIF; 
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(***  Wing  and  Tail  Area  Model  - Safety  Criteria  - Network  Option  ***) 

/*  Group  A > 
\ * ) 
(* 


( NWREC; 

0. 

• 2, 

(* 

NETWORK  RECOVERY  INDICATOR 

*) 

RWP 

0. 

• 4, 

(* 

RW  CHANNEL  STATE 

*) 

RWV 

0. 

.4 , 

(* 

RW  VALVE  STATE 

*) 

LWP 

0. 

• 4, 

(* 

LW  CHANNEL  STATE 

*) 

LWV 

0. 

• 4, 

(* 

LW  VALVE  STATE 

*) 

TLP 

0. 

• 4, 

(* 

TL  CHANNEL  STATE 

*) 

TLV 

0. 

.4, 

<* 

TL  VALVE  STATE 

*) 

HYD 

0. 

• 2, 

(* 

HYDRAULIC  SYSTEM  STATE 

*) 

ELMC : 

0. 

• 4, 

(* 

ELECTRIC  SYSTEM  SUPPLY  STATE 

*) 

ONREC: 

0. 

• 2, 

(* 

OTHER  NODES  FAILURE  RECOVERY 

*) 

NFAIL: 

0. 

.4); 

(* 

NO.  OF  FAILED  ELEMENTS 

*) 

START  = (’0,  4,  4,  4,  4,  4,  4,  2,  4.  0,  0 ); 
PRUNE IF  NFAIL  > 2; 

DEATHIF  RWV  = 0; 

DEATHIF  LWV  = 0; 

DEATHIF  TLV  = 0; 

DEATHIF  NWREC  + ONREC  > 1; 


LIST  = 2; 

TIME  = 3.0; 

PRUNE  = 1.0E-16; 

ECHO  = 0 ; 


LAMC  = 50.0E-6;  (* 
LAMPOS  = 10.0E-6;  (* 
LAMSD  = 20.0E-6;  (* 
LAMV  = 15.0E-6;  (* 
VJAM  = 3.3333E-5;  (* 


PROCESSOR  FAILURE  RATE  *) 
POSITION  SENSOR  FAILURE  RATE  *) 
SERVODRIVE  GROUP  FAILURE  RATE  *) 
VALVE  GROUP  FAILURE  RATE  *) 
ACTUATOR  JAM  FAILURE  FRACTION  *) 


LAMNODH  = 42.5E-6; 
LAMDIUH  = 37 . 5E-6; 
LAMHYD  = 45.  OE-6; 


(*  NODE  FAILURE  RATE  - HARSH  *) 
(*  DIU  FAILURE  RATE  - HARSH  *) 
(*  HYDRAULIC  SYSTEM  FAIL  RATE  *) 


LAMPSH 

LAMEL 

NWMEAN 

NWSTD 

LAMON 


25. OE-6; 

(*  LOCAL  POWER  SUPPLY 

RATE  - HARSH 

*) 

50 . OE-6  ; 

(*  ELMC  FAILURE  RATE 

*) 

3. OE-4; 

(*  NW  RECOVERY  TIME  - 

MEAN 

*) 

1 . OE-4; 

(*  NW  RECOVERY  TIME  - 

STD  DEV 

*) 

68. OE-6; 

(*  OTHER  NODE  FAILURE 

RATE 

*) 

( * * * RW 

PROCESSOR  GROUP  / DIU  FAILURE 

TRANSITIONS 

* * * 

IF  NWREC  = 0 AND  ONREC  = 0 THEN 
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IF  RWP  > 0 THEN 

TRANTO  RWP=RWP-1,  NFAIL=NFAIL+1  BY  RWP*  ( 2*(LAMC  + LAMPOS) 
+ (LAMDIUH  + LAMPSH)  ); 

ENDIF; 

ENDIF; 

(***  RW  VALVE  GROUP  FAILURES  ***) 

IF  RWV  > 0 AND  NWREC  = 0 AND  ONREC  = 0 THEN 
IF  NFAIL  = 0 

TRANTO  RWV=0,  NFAIL=NFAIL f 1 BY  RWV*VJAM*LAMV; 

TRANTO  RWV=RWV-1,  NFAIL=NFAIL+1  BY  RWV* (1 . 0-VJAM) *LAMV- 

ENDIF; 


(*  RW  NODE  FAILURES  *) 

IF  NWREC  = 0 AND  ONREC  = 0 THEN 

IF  RWP  < 3 OR  LWP  < 3 OR  TLP  < 3 THEN 

(*  TEMPORARY  EXHAUSTION  FAILURE  *) 
TRANTO  RWP=RWP-1 , NWREC=2,  NFAIL=NFAIL+1 
BY  2*LAMNODH  /3; 

ELSE 

(*  TEMPORARY  EXHAUSTION  NOT  POSSIBLE  *) 

IF  RWP  > 0 THEN 
IF  NFAIL=0  THEN 

TRANTO  RWP=RWP-1,  NWREC=1,  NFAIL=NFAIL+1 
BY  RWP*LAMNODH; 

ELSE 

TRANTO  RWP=RWP-1,  NFAIL=NFAIL+1 
BY  RWP*LAMNODH; 

ENDIF; 


ENDIF; 

ENDIF; 


ENDIF; 


(***  LW  PROCESSOR  GROUP  / DIU  FAILURE  TRANSITIONS  ***) 

IF  NWREC  = 0 AND  ONREC  = 0 THEN 
IF  LWP  > 0 THEN 

TRANTO  LWP=LWP-1,  NFAIL=NFAIL+1  BY  LWP* ( 2* (LAMC  + LAMPOS) 
+ (LAMDIUH  + LAMPSH)  ); 

ENDIF; 

ENDIF; 


(***  LW  VALVE  GROUP  FAILURES  ***) 

IF  LWV  > 0 AND  NWREC  = 0 AND  ONREC  = 0 THEN 
IF  NFAIL  = 0 

TRANTO  LWV=0 , NFAIL=NFAIL+1  BY  LWV*VJAM*LAMV; 
TRANTO  LWV=LWV-1,  NFAIL=NFAIL+1  BY  LWV* (1 . 0-VJAM) *LAMV; 
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ENDIF; 


(*  LW  NODE  FAILURES  *) 

IF  NWREC  = 0 AND  ONREC  = 0 THEN 

IF  RWP  < 3 OR  LWP  < 3 OR  TLP  < 3 THEN 

(*  TEMPORARY  EXHAUSTION  FAILURE  *) 

TRANTO  LWP=LWP-1,  NWREC=2,  NFAIL=NFAIL+1 
BY  2*LAMNODH  /3; 

else 

(*  TEMPORARY  EXHAUSTION  NOT  POSSIBLE  *) 

IF  LWP  > 0 THEN 
IF  NFAIL=0  THEN 

TRANTO  LWP=LWP-1,  NWREC=1,  NFAIL=NFAIL+1 
BY  LWP*LAMNODH; 

ELSE 

TRANTO  LWP=LWP-1,  NFAIL=NFAIL+1 
BY  LWP*LAMNODH; 

ENDIF; 

ENDIF; 

ENDIF; 

ENDIF; 

(***  TL  PROCESSOR  GROUP  / DIU  FAILURE  TRANSITIONS  ***) 


IF  NWREC  = 0 AND  ONREC  = 0 THEN 
IF  TLP  > 0 THEN 

TRANTO  TLP=TLP-1,  NFAIL=NFAIL+1 
+ (LAMDIUH  + LAMPSH)  ) ; 

ENDIF; 

ENDIF; 


BY  TLP*  ( 2* (LAMC  + LAMPOS) 


(***  XL  VALVE  GROUP  FAILURES  ***) 


IF  TLV  > 0 AND  NWREC  = 0 AND  ONREC  = 0 THEN 


IF  NFAIL  = 0 

TRANTO  TLV=0 
TRANTO  TLV=TLV-1, 


, NFAIL=NFAIL+1  BY  TLV*VJAM*LAMV; 
NFAIL=NFAIL+1  BY  TLV* (1 . 0-VJAM) *LAMV; 


ENDIF; 


(*  TL  NODE  FAILURES  *) 


IF  NWREC  =•  0 AND  ONREC  = 0 THEN 

IF  RWP  < 3 OR  LWP  < 3 OR  TLP  < 3 THEN 

(*  TEMPORARY  EXHAUSTION  FAILURE  *) 
TRANTO  TLP=TLP-1,  NWREC=2,  NFAIL=NFAIL+1 
BY  2*LAMNODH  /3; 

ELSE 

(*  TEMPORARY  EXHAUSTION  NOT  POSSIBLE  *) 
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IF  TLP  > 0 THEN 
IF  NFAIL=0  THEN 

TRANTO  TLP=TLP-1,  NWREC-1,  NFAIL=NFAIL+1 
BY  TLP*LAMNODH; 

ELSE 

TRANTO  TLP=TLP-1,  NFAIL=NFAIL+1 
BY  TLP*LAMNODH; 

END IF; 

ENDIF; 

END IF; 

ENDIF; 


(*  NEARLY  COINCIDENT  FAULTS  - RECOVERIES  *) 

IF  NWREC  = 1 THEN 

(*  NETWORK  RECOVERY  *) 

TRANTO  NWREC  = 0 BY  < NWMEAN,  NWSTD  >; 

(*  SAME  NODE  SET  *) 

TRANTO  NWREC=NWREC+1,  NFAIL=NFAIL+1 
BY  6*LAMN0DH; 

ENDIF; 

IF  ONREC  = 1 THEN  (*  OTHER  NODE  SET  *) 

TRANTO  NWREC=NWREC+1,  NFAIL=NFAIL+1 
BY  6*LAMNODH; 

ENDIF; 


(**  OTHER  NODE  FAILURES  **) 

IF  NWREC  = 0 AND  ONREC  = 0 THEN 

IF  RWP  < 3 OR  LWP  < 3 OR  TLP  < 3 THEN 

(*  VULNERABLE  TO  TEMPORARY  EXHAUSTION  *) 
TRANTO  ONREC=2,  NFAIL=NFAIL+1  BY  LAMON/3; 

ELSE 

IF  NFAIL  = 0 

TRANTO  ONREC  = 1,  NFAIL=NFAIL+1  BY  2*LAMON; 

ENDIF; 

ELSE  (*  NEARLY  COINCIDENT  NW  FAULT  *) 

IF  NWREC  > 0 

TRANTO  ONREC=l,  NFAIL=NFAIL+1  BY  LAMON; 

IF  ONREC  > 0 THEN 

(*  NETWORK  RECOVERY  *) 

TRANTO  ONREC  = 0 BY  < NWMEAN,  NWSTD  >; 

(*  NCF  - OTHER  NODES  *) 

TRANTO  ONREC=ONREC+l , NFAIL=NFAIL+1  BY  LAMON; 
ENDIF; 

ENDIF; 


(*  HYDRAULIC  SYSTEM  FAILURES  *) 
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IF  HYD  > 0 AND  NWREC  = 0 AND  ONREC  - 0 
AND  (HYD-NFAIL  >=  0 ) THEN 

TRANTO  RWV=RWV-2,  LWV=LWV-2,  TLV=TLV-2,  HYD=HYD-1,  NFAIL=NFAIL+1 
BY  RWV* (RWV-1) *LWV* (LWV-1) *TLV* (TLV-1) *LAMHYD  / 

( 2*  (2*HYD) **2  * (2*HYD-1) **3  ); 

ENDIF; 


(***★  ELECTRIC  POWER  DISTRIBUTION  ***) 

IF  ELMC  > 0 AND  NWREC  = 0 AND  ONREC  = 0 THEN 

TRANTO  RWP=RWP-1,  LWP=LWP-1,  TLP=TLP-1,  ELMC=ELMC-1, 
NFAIL=NFAIL+1  BY  RWP*  LWP*  TLP*  LAMEL  / ( ELMC* *2) ; 


ENDIF; 


(***  Air  Model  - Safety  Criteria  - Network  Option 

' Group  B 


SPACE 

= ( AIRNOD : 

0..4, 

(* 

AIRREC: 

0 • . 3, 

(* 

AIRDIU: 

0..4, 

(* 

AOA: 

0 . • 4, 

(* 

AOAREC : 

0..2, 

(* 

AOS: 

0..4, 

(* 

AOSREC : 

0..2, 

(* 

THROT : 

0..4, 

(* 

THROTREC : 

0.  .1, 

(* 

FTP: 

0.  .4, 

(* 

FTPREC: 

0..2, 

(* 

ROOT: 

0.  .4, 

(* 

ELMC : 

0.  .4, 

(* 

ONREC: 

0..3, 

(* 

NFAIL : 

0..4); 

(* 

START  = 

( 4,  0,  4,  4, 

0,  4,  0, 

4, 

PRUNE IF 

NFAIL  > 2; 

DEATHIF 

FTP  < 2; 

DEATHIF 

FTPREC  > 1; 

*) 


AIR  NODE  *j 
NETWORK  RECOVERY  INDICATOR  *) 
FORWARD  DIU  STATE  INDICATOR  *) 
AOA  SENSOR  *) 
AOA  RECOVERY  INDICATOR  *) 
AOS  SENSOR  *) 
AOS  RECOVERY  INDICATOR  *) 
THROTTLE  POSITION  SENSOR  *) 
THROTTLE  FAILURE  INDICATOR  *) 
FTP  CHANNEL  STATUS  *) 
FTP  CHANNEL  RECOVERY  IND.  *) 
ROOT  LINK  STATUS  *) 
ELECTRIC  POWER  STATE  *) 
OTHER  NODES  IN  A SINGLE  NETWORK  *) 
NO.  OF  FAILED  ELEMENTS  *) 

0,  4,  0,  4,  4,  0,  0 ); 


DEATHIF  AO ARE C > 1 OR  AOSREC  > 1; 

DEATHIF  AOA-AOAREC  < 1 OR  AOS-AOSREC  < 1; 

DEATHIF  THROT-THROTREC  < 1; 

DEATHIF  AIRREC  = 3 OR  ONREC  = 3; 

DEATHIF  AIRREC  + ONREC  > 1; 

DEATHIF  AIRREC  + AOAREC  + AOSREC  > 1; 

DEATHIF  ONREC  + AOAREC  + AOSREC  > 1; 

DEATHIF  ROOT  < 3 AND  ( AOAREC  > 0 OR  AOSREC  > 0 OR  THROTREC  > 0 

OR  AIRREC  > 0 OR  ONREC  > 0 ) ; 

LIST  = 3; 

TIME  = 3.0; 

PRUNE  = 1.0E-16; 

ECHO  = 0; 


LAMANG  = 33.0E-6; 
LAMPR£SS=  20.0E-6; 
LAMPOS  = 10.0E-6; 


(*  FLOW  ANGLE  SENSOR  FAILURE  RATE 
(*  PRESSURE  SENSOR  FAILURE  RATE 
(*  POSITION  SENSOR  FAILURE  RATE 


*) 

*) 
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LAMNOD 

= 17.0E-6; 

(* 

LAMDIU 

= 15.0E-6; 

(* 

RECMEAN 

= 3.0E-4; 

(* 

RECSTD 

= 1.0E-4; 

<* 

NWMEAN 

= 3.0E-4; 

(* 

NWSTD 

= 1.0E-4; 

(* 

LAMPS 

= 10.0E-6; 

(* 

LAMEL 

= 50.0E-6; 

(* 

LAMFTP 

= 200.0E-6; 

(* 

LAMROOT 

= 15.0E-6; 

(* 

FTPMEAN 

= 5.0E-6; 

(* 

FTPSTD 

= 1.0E-6; 

(* 

LAMON 

= 255.0E-6; 

(* 

NODE  FAILURE  RATE  - CONDITIONED 
DIU  FAILURE  RATE  - CONDITIONED 
RECOVERY  TIME  MEAN 
RECOVERY  TIME  STD  DEV 
NW  RECOVERY  TIME  MEAN 
NW  RECOVERY  TIME  STD  DEV 

LOCAL  POWER  SUPPLY  RATE  - CONDITIONED 
ELECTRIC  POWER  CENTER  FAILURE  RATE 
FTP  CHANNEL  FAILURE  RATE 
FTP  NETWORK  INTERFACE  FAILURE  RATE 
FTP  RECOVERY  TIME  MEAN 
FTP  RECOVERY  TIME  STD  DEV 

OTHER  NODES  ON  SINGLE  NW  FAIL  RATE 


*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 


{*  AOA  SENSOR  FAILURES  AND  RECOVERIES  *) 

IF  AOA  > 0 AND  AOAREC  = 0 AND  AOSREC  = 0 

AND  FTPREC  = 0 AND  AIRREC  = 0 AND  ONREC  = 0 THEN 
IF  NFAIL  = 0 OR  AOA  = 2 THEN 

TRANTO  AOA  = AOA-1,  AOAREC=AOAREC+l , NFAIL=NFAIL+1 
BY  AOA*LAMANG; 

ELSE 

IF  ROOT  = 2 THEN 

(*  SINGLE  NETWORK  SUSCEPTIBILITY  *) 

TRANTO  AOA= AOA-1,  AOAREC=AOAREC+l,  NFAIL=NFAIL+1 
BY  (2/3) *LAMANG; 

TRANTO  AOA=AOA-l,  NFAIL=NFAIL+1 
BY  {(AOA  - 2)  + 4/3  ) *LAMANG; 

ELSE 

TRANTO  AOA  = AOA-1,  NFAIL=NFAIL+1 
BY  AOA*LAMANG; 

ENDIF; 


ENDIF; 


ELSE  (*  NEARLY  COINCIDENT  SENSOR-NETWORK  *) 

IF  AIRREC  >0  (*  SAME  NODE  SET  *) 

TRANTO  AOA  = AOA-1,  AOAREC=AOAREC+ 1 , NFAIL=NFAIL+1 
BY  (AOA+1 ) *LAMANG  /2; 

IF  ONREC  >0  (*  OTHER  NODES  *) 

TRANTO  AOA  = AOA-1,  AOAREC=AOAREC+l,  NFAIL=NFAIL+1 
BY  AOA*LAMANG  /2; 

IF  AOAREC  > 0 THEN  (*  RECOVERY  OR  SYSTEM  LOSS  *) 
TRANTO  AOAREC  = 0 BY  < RECMEAN,  RECSTD  >; 

TRANTO  AOA  = AOA-1,  AOAREC=AOAREC+l,  NFAIL=NFAIL+1 
BY  AOA*LAMANG; 

ENDIF; 

ENDIF; 
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(*  AOS  SENSOR  FAILURES  AND  RECOVERIES  *) 

IF  AOS  > 0 AND  AOAREC  = 0 AND  AOSREC  = 0 

AND  FTPREC  = 0 AND  AIRREC  = 0 AND  ONREC  = 0 THEN 
IF  NFAIL  = 0 OR  AOS  = 2 THEN 

TRANTO  AOS  = AOS-1,  AOSREC=AOSREC+l , NFAI L=NFAI L+ 1 
BY  AOS*LAMANG; 

ELSE 

IF  ROOT  = 2 THEN 

(*  SINGLE  NETWORK  SUSCEPTIBILITY  *) 

TRANTO  AOS=AOS-l,  AOSREC=AOSREC+l,  NFAIL=NFAIL+1 
BY  (2/3) *LAMANG; 

TRANTO  AOS=AOS-l,  NFAIL=NFAIL+1 
BY  ((AOS  - 2)  + 4/3  ) *LAMANG; 

ELSE 

TRANTO  AOS  = AOS-1,  NFAIL=NFAIL+1 
BY  AOS*LAMANG; 

ENDIF; 


END IF; 


ELSE  (*  NEARLY  COINCIDENT  SENSOR-NETWORK  *) 

IF  AIRREC  >0  (*  SAME  NODE  SET  *) 

TRANTO  AOS  = AOS-1,  AOSREC=AOSREC+l,  NFAIL=NFAIL+1 
BY  (AOS+1 ) *LAMANG  /2; 

IF  ONREC  >0  (*  OTHER  NODES  *) 

TRANTO  AOS  = AOS-1,  AOSREC=AOSREC+l,  NFAI L=NFAI L+ 1 
BY  AOS*LAMANG  /2; 

IF  AOSREC  > 0 THEN  (*  RECOVERY  OR  SYSTEM  LOSS  *) 
TRANTO  AOSREC  = 0 BY  < RECMEAN,  RECSTD  >; 

TRANTO  AOS  = AOS-1,  AOSREC=AOSREC+l,  NFAIL=NFAIL+1 
BY  AOS*LAMANG; 

ENDIF; 

ENDIF; 


(*  THROTTLE  SENSOR  FAILURES  AND  RECOVERIES  *) 

IF  THROT  > 0 AND  AOAREC  = 0 AND  AOSREC  = 0 

AND  FTPREC  = 0 AND  AIRREC  = 0 AND  ONREC  = 0 THEN 
IF  THROT  = 2 THEN 

TRANTO  THROT=THROT-l , THROTREC=THROTREC+l , NFAIL=NFAIL+1 
BY  THROT*LAMPOS ; 

ELSE 

IF  ROOT  = 2 THEN 

(*  SINGLE  NETWORK  SUSCEPTIBILITY  *) 

TRANTO  THROT=THROT-l , THROTREC=THROTREC+l,  NFAIL=NFAIL+1 
BY  (2/3) *LAMPOS; 

TRANTO  THROT=THROT-l,  NFAIL=NFAIL+1 
BY  ((THROT  - 2)  + 4/3  ) *LAMPOS; 

ELSE 

TRANTO  THROT  = THROT-1,  NFAIL=NFAIL+1 
BY  THROT *LAMPOS; 


ENDIF; 

ENDIF; 

ENDIF; 


(*  AIR  AREA  NODE  FAILURES  *) 

IF  AIRNOD  > 0 AND  AIRREC  = 0 AND  p _ n THFN 

AOAREC  = 0 AND  AOSREC  = 0 AND  FTPREC  = 0 AND  ONREC  - 0 THEN 

IF  AOA  < 3 OR  AOS  < 3 THEN 

(*  TEMPORARY  EXHAUSTION  FAILURE  *) 

TRANTO  AIRNOD=AIRNOD-l,  AIRDIU=AIRDIU-1, 

AOA=AOA-l,  AOS-AOS-1,  THROT=THROT-l , ROOT=ROOT-1, 

AIRREC=2,  NFAIL=NFAIL+1  BY  (2/3) *LAMNOD; 

(*  TEMPORARY  EXHAUSTION  AVOIDED  *) 

TRANTO  AIRNOD=AIRNOD-l,  AIRDIU=AIRDIU-1, 

AOA=AOA-l,  AOS=AOS-l,  THROT=THROT-l,  ROOT=ROOT-l, 
NFAIL=NFAIL+1  BY  ((  AIRNOD-2)  + 4/3)*LAMNOD; 

ELSE  (*  NO  TEMPORARY  EXHAUSTION  VULNERABILITY  *) 

IF  ROOT  = 2 THEN  (*  SINGLE  NETWORK  VULNERABILITY  *) 
TRANTO  AIRNOD=AIRNOD-l , AIRDIU=AIRDIU-1, 

AOA=AOA-l,  AOS-AOS-1,  THROT=THROT-l , ROOT-ROOT- 1, 
AIRREC=AIRREC+1 , NFAIL=NFAIL+1  BY  (2/3) * LAMNOD; 

TRANTO  AIRNOD-AIRNOD-1,  AIRDIU=AIRDIU-1, 

AOA=AOA-l r AOS=AOS-l,  THROT=THROT-l , ROOT=ROOT-l, 
NFAIL=NFAIL+1  BY  ((  AIRNOD-2)  + 4/3)*LAMNOD; 

ELSE  (*  NO  SINGLE  NETWORK  VULNERABILITY  ) 

(*  IN  THIS  MODEL  FAULTS  ARE  ON  SEPARATE  "CHANNELS" 
(*  FORWARD  NODE  FAILURE  AFFECTS  ROOT  LINK  AND  DIU  *) 

IF  NFAIL  = 0 THEN 

TRANTO  AIRNOD=AIRNOD-1,  AIRDIU=AIRDIU-1 , 

AOA=AOA- 1 , AOS=AOS - 1 , T HROT=T HROT - 1 , ROOT=ROOT-l, 
AIRREC=AIRREC+1,  NFAIL=NFAIL+1  BY  AIRNOD*  LAMNOD; 

ELSE 

TRANTO  AIRNOD=AIRNOD-l , AIRDIU=AIRDIU-1, 
AOA=AOA-l,  AOS=AOS-lf  THROT=THROT-l , ROOT-ROOT-1, 
NFAIL=NFAIL+1  BY  ROOT*  AOA*AOS*  THROT*  LAMNOD/ 

( (AIRNOD+ELMC-4) * AIRDIU**2  ); 

F.MDTF: 


ENDIF; 

ENDIF; 

(*  NEARLY  COINCIDENT  NETWORK-SENSOR  FAILURES  *) 

IF  AIRREC  = 1 THEN  (*  SAME  NODE  SET  *) 

(*  NETWORK  RECOVERY  *) 

TRANTO  AIRREC  = 0 BY  < NWMEAN,  NWSTD  >; 


TRANTO  AIRREC  = 3,  NFAIL=NFAIL+1  BY  2*LAMNOD; 

ENDIF; 

IF  ONREC  = 1 

TRANTO  AIRREC  = 3,  NFAIL=NFAIL+1  BY  2*LAMNOD; 

IF  AOAREC  = 1 OR  AOSREC  = 1 

TRANTO  AIRNOD=AIRNOD-l,  AIRREC=AIRREC+1,  NF A I L=NF A I L+ 1 BY 
AIRNOD*LAMNOD  /2; 


ENDIF; 


(*  OTHER  NODE  FAILURES  *) 

IF  AIRREC  = 0 AND 

AOAREC  = 0 AND  AOSREC  = 0 AND  FTPREC  = 0 AND  ONREC  = 0 THEN 
IF  AOA  < 3 OR  AOS  < 3 THEN 

(*  TEMPORARY  EXHAUSTION  VULNERABLE  *) 

TRANTO  ONREC=2,  NFAIL=NFAIL+1  BY  LAMON/3; 

ELSE 

IF  ROOT  = 2 THEN  (*  SINGLE  NW  VULNERABLE  *) 

TRANTO  ONREC=l,  NFAIL=NFAIL+1  BY  LAMON/3; 

ELSE 

IF  NFAIL  = 0 TRANTO  ONREC=l,  NFAIL=NFAIL+1  BY 
2*LAMON; 

ENDIF; 

ENDIF; 

ELSE 

(*  NEARLY  COINCIDENT  FAILURES-  RECOVERIES  *) 

IF  ONREC  = 1 THEN 

TRANTO  ONREC  = 0 BY  < NWMEAN,  NWSTD  >; 

TRANTO  ONREC  = 3,  NFAIL=NFAIL+1  BY  LAMON; 

ENDIF; 

IF  AIRREC  = 1 

TRANTO  ONREC  = 3,  NFAIL=NFAIL+1  BY  LAMON; 

IF  AOAREC=l  OR  AOSREC  = 1 

TRANTO  ONREC=l,  NFAIL=NFAIL+1  BY  LAMON; 

ENDIF; 


(*  FORWARD  DIU  FAILURES  *) 

IF  AIRDIU  > 0 AND  AIRREC  = 0 AND 

AOAREC  = 0 AND  AOSREC  = 0 AND  FTPREC  = 0 AND  ONREC  = 0 THEN 

TRANTO  AIRDIU=AIRDIU-1 , AOA=AOA-l,  AOS=AOS-l,  THROT=THROT-l , 
NFAIL=NFAIL+1  BY  AOA*AOS*  THROT* ( LAMDIU  + LAMPS  ) / AIRDIU**2; 


ENDIF; 


(*  FTP  CHANNEL  FAILURES  *) 

IF  FTP  > 0 AND  AOAREC  = 0 AND  AOSREC  = 0 
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AND  AIRREC  = 0 AND  FTPREC  = 0 AND  ONREC  - 0 THEN 
IF  NFAIL  = 0 THEN 

TRANTO  FTP-FTP-1,  FTPREC-FTPREC+1,  ROOT=ROOT-l, 
BY  FTP*LAMFTP; 

ELSE 

TRANTO  FTP=FTP-1,  ROOT=ROOT-l,  NFAIL=NFAIL+1 
BY  ROOT*LAMFTP; 

ENDIF; 


NFAIL=NFAIL+1 


ELSE 

IF  FTPREC  > 0 THEN 

(*  FTP  CHANNEL  RECOVERY  *) 

TRANTO  FTPREC=FTPREC-1  BY  < FTPMEAN,  FTPSTD  >; 

(*  COINCIDENT  FAULT  *) 

TRANTO  FTP-FTP-1,  FTPREC-FTPREC+1,  ROOT=ROOT-l,  NFAIL-NFAIL+1 
BY  FTP*LAMFTP; 

ENDIF; 


ENDIF; 


(*  NETWORK  INTERFACE  FAILURES  *) 

IF  ROOT  > 2 AND  AOAREC  = 0 AND  AOSREC  = 0 

AND  FTPREC  = 0 AND  AIRREC  = 0 AND  ONREC  =0 

TRANTO  ROOT-ROOT- 1,  NFAIL=NFAIL+1  BY  ROOT*LAMROOT; 


(***  ELECTRIC  POWER  DISTRIBUTION  FAILURES  ***) 

IF  ELMC  > 0 AND  AOAREC  = 0 AND  AOSREC  =0 

AND  FTPREC  = 0 AND  AIRREC  = 0 AND  ONREC  = 0 THEN 

(*  ELMC  FAILURE  AFFECTS  DIU,  FTP  AND  ROOT  LINK  *) 

(*  IN  THIS  MODEL  FAULTS  ON  DIFFERENT  "CHANNELS"  *) 

TRANTO  AIRDIU— AIRDIU-1, 

AQA-AOA-1,  AOS— AOS- 1,  FTP-FTP-1,  THROT— THROT-1 , 
ROOT-ROOT-1,  ELMC-ELMC-1, 

NFAIL-NFAIL+1  BY  ROOT*  AOA*  AOS*  THROT* 

LAMEL  / ( (AIRNOD+ELMC-4) * AIRDIU**2  ); 


ENDIF; 
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( * ★* 
(* 

(* 


SPACE 


START 

PRUNEIF 

DEATHIF 


DEATHIF 

DEATHIF 


LIST  = 
TIME  = 
PRUNE  = 
ECHO  = 

LAMPOS 

LAMNOD 

LAMDIU 

POSMEAN 

POSSTD 

NWMEAN 

NWSTD 

LAMPS 

LAMEL 

LAMFTP 

LAMROOT 

FTPMEAN 

FTP STD 

LAMGYRO 
LAMACC 
LAMOD 
(*  DIUACT 


Forward  Area  Model  - Safety  Criteria  - Bus  Option  ***) 
Group  A *) 

*) 


= ( FWDIU:  0 . . 4, 

PITSTK:  0 . . 4, 

PITREC:  0..2, 

ROLSTK:  0..4, 

ROLREC:  0..2, 

YAWPED:  0..4, 

YAWREC:  0..2, 

FTP:  0 . . 4, 

FTPREC:  0..2, 

ROOT:  0 . . 4, 

NFAIL : 0 . . 4 ) ; 


(*  FORWARD  DIU  STATE  INDICATOR  *) 
(*  PITCH  COMMAND  SENSOR  *) 
(*  PITCH  SENSOR  RECOVERY  INDICATOR  *) 
(*  ROLL  COMMAND  SENSOR  *) 
(*  ROLL  SENSOR  RECOVERY  INDICATOR  *) 
(*  YAW  COMMAND  SENSOR  *) 
(*  YAW  SENSOR  RECOVERY  INDICATOR  *) 
(*  FTP  CHANNEL  STATUS  *) 
(*  FTP  CHANNEL  RECOVERY  IND.  *) 
(*  ROOT  LINK  STATUS  *) 
(*  NO.  OF  FAILED  ELEMENTS  *) 


( 4,  4,  0,  4,  0,  4,  0,  4,  0,  4,  0 ); 


NFAIL  > 2; 


PITREC  > 1 OR  ROLREC  > 1 OR 
YAWREC  > 1; 


PITSTK-PITREC  < 1 OR  ROLSTK-ROLREC  < 1 OR  YAWPED-YAWREC  < 1; 
FTP  - FTPREC  < 1; 


2; 

3.0; 

1.0E-16; 

0; 


= 10.0E-6; 
= 15.0E-6; 
= 15.0E-6; 
= 3.0E-4; 

= 1.0E-4; 

= 3.0E-4; 

= 1.0E-4; 


(*  POSITION  SENSOR  FAILURE  RATE  *) 
(*  NODE  FAILURE  RATE  - CONDITIONED  *) 
(*  DIU  FAILURE  RATE  - CONDITIONED  *) 
(*  RECOVERY  TIME  MEAN  *) 

(*  RECOVERY  TIME  STD  DEV  *) 

(*  NW  RECOVERY  TIME  MEAN  *) 

(*  NW  RECOVERY  TIME  STD  DEV  *) 


= 10.0E-6; 

= 50.0E-6; 

= 200.0E-6; 
= 15.0E-6; 

= 5.0E-6; 

= 1.0E-6; 


(*  LOCAL  POWER  SUPPLY  RATE  - CONDITIONED  *) 


(*  ELECTRIC  POWER  CENTER  FAILURE  RATE  *) 
(*  FTP  CHANNEL  FAILURE  RATE  *) 
(*  FTP  NETWORK  INTERFACE  FAILURE  RATE  *) 
(*  FTP  RECOVERY  TIME  MEAN  *) 
(*  FTP  RECOVERY  TIME  STD  DEV  *) 


= 50.0E-6; 

= 30.0E-6; 

= 127.5E-6; 

= 0.10;  *) 


(*  GYRO  FAILURE  RATE 
(*  ACCELEROMETER  FAILURE  RATE 
(*  OTHER  DIUS  ON  SINGLE  BUS 

(*  DIU  ACTIVE  FAILURE  FRACTION 


*) 

*) 
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(*  pitch  command  sensor  failures  and  recoveries  *) 

IF  PITSTK  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 
AND  FTPREC  = 0 THEN 

IF  NFAIL  = 0 OR  PITSTK  = 2 THEN 

TRANTO  PITSTK  = PITSTK-1,  PITREC=PITREC+1,  NFAI L=NF AI L+ 1 
BY  PITSTK*LAMPOS; 

ELSE 

TRANTO  PITSTK  * PITSTK-1,  NFAIL=NFAIL+1 
BY  PITSTK*LAMPOS; 

ENDIF; 


ELSE  (*  NEARLY  COINCIDENT  FAILURES  *) 

IF  PITREC  > 0 THEN  (*  RECOVERY  OR  SYSTEM  LOSS  *) 

TRANTO  PITREC  = 0 BY  < POSMEAN,  POSSTD  >; 

TRANTO  PITSTK  = PITSTK-1,  PITREC=PITREC+1,  NFAIL=NFAIL+1 
BY  PITSTK*LAMPOS; 

ENDIF; 

ENDIF; 


{*  ROLL  COMMAND  SENSOR  FAILURES  AND  RECOVERIES  *) 

IF  ROLSTK  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 
AND  FTPREC  = 0 THEN 

IF  NFAIL  = 0 OR  ROLSTK  = 2 THEN 

TRANTO  ROLSTK  = ROLSTK-1,  ROLREC=ROLREC+l , NFAIL=NFAIL+1 
BY  ROLSTK*LAMPOS ; 

ELSE 

TRANTO  ROLSTK  = ROLSTK-1,  NFAIL=NFAIL+1 
BY  ROLSTK*LAMPOS ; 

ENDIF; 


ELSE  (*  NEARLY  COINCIDENT  FAILURES  *) 

IF  ROLREC  > 0 THEN  (*  RECOVERY  OR  SYSTEM  LOSS  *) 

TRANTO  ROLREC  « 0 BY  < POSMEAN,  POSSTD  >; 

TRANTO  ROLSTK  = ROLSTK-1,  ROLREC=ROLREC+l , NFAIL=NFAIL+1 
BY  ROLSTK*LAMPOS; 

ENDIF; 

ENDIF; 


(*  YAW  COMMAND  SENSOR  FAILURES  AND  RECOVERIES  *) 

IF  YAWPED  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 
AND  FTPREC  = 0 THEN 

IF  NFAIL  = 0 OR  YAWPED  = 2 THEN 

TRANTO  YAWPED  = YAWPED-1,  YAWREC=YAWREC+1,  NFAIL-NFAIL+1 

BY  YAWPED *LAMPOS; 

ELSE 


TRANTO  YAWPED  = YAWPED- 1,  NF A I L=NF  A I L+ 1 
BY  YAWP  ED  * LAMPOS ; 

ENDIF; 


ELSE  (*  NEARLY  COINCIDENT  FAILURES  *) 

IF  YAWREC  > 0 THEN  (*  RECOVERY  OR  SYSTEM  LOSS  *) 

TRANTO  YAWREC  = 0 BY  < POSMEAN,  POSSTD  >; 

TRANTO  YAWPED  = YAWPED- 1,  YAWREC=YAWREC+1 , NFAIL=NFAIL+1 
BY  YAWPED *LAMPOS; 

ENDIF; 

ENDIF; 


(*  ***  FORWARD  DIU  FAILURES  ***  * 

(*  PASSIVE  FAILURE  TRANSITIONS  LISTED  HERE.  ACTIVE  * 

(*  FAILURE  TRANSITIONS  IN  BUS  AND  INTERFACE  FAILURE  AREA.  * 

IF  FWDIU  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND 
YAWREC  = 0 AND  FTPREC  = 0 THEN 

TRANTO  FWDIU=FWDIU-1,  PITSTK-PITSTK-1,  ROLSTK=ROLS TK- 1 , YAWPED= 
YAWP ED- 1,  NFAIL=NFAIL+1  BY  PITSTK*  ROLSTK*  YAWPED*  ( LAMDIU* 

(1 . 0-DIUACT)  + LAMPS  ) / FWDIU**2; 

IF  FWDIU  > PITSTK  (*  AFFECTED  DIU  HAS  FAILED  PITSTK  *) 

TRANTO  FWDIU=FWDIU-1,  ROLSTK=ROLSTK-l , YAWPED= 

YAWPED-1,  NFAIL=NFAIL+1  BY  (FWDIU-PITSTK) *ROLSTK* 

YAWPED* ( LAMDIU* (1. 0-DIUACT)  + LAMPS  ) / FWDIU**2; 

IF  FWDIU  > ROLSTK  (*  AFFECTED  DIU  HAS  FAILED  ROLSTK  *) 

TRANTO  FWDIU=FWDIU-1,  PITSTK=PITSTK-1,  YAWPED= 

YAWPED-1,  NFAIL=NFAIL+1  BY  PITSTK* (FWDIU- ROLSTK) * 

YAWPED* ( LAMDIU* (1. 0-DIUACT)  + LAMPS  ) / FWDIU**2; 

IF  FWDIU  > YAWPED  (*  AFFECTED  DIU  HAS  FAILED  YAWPED  *) 

TRANTO  FWDIU=FWDIU-1,  PITSTK=PITSTK-1,  ROLSTK=ROLSTK-l , 
NFAIL=NFAIL+1  BY  P ITSTK* ROLSTK* (FWDIU- YAWPED ) * 

( LAMDIU* (1 . 0-DIUACT)  + LAMPS  ) / FWDIU**2; 

ENDIF; 


(*  FTP  CHANNEL  FAILURES  *) 

IF  FTP  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 
AND  FTPREC  = 0 THEN 

IF  NFAIL  = 0 OR  FTP  = 2 THEN 

TRANTO  FWDIU=FWDIU-1,  PITSTK=PITSTK-1 , ROLSTK=ROLSTK-l , YAWPED= 
YAWPED-1,  FTP=FTP-1,  FTPREC=FTPREC+1,  ROOT=ROOT-l,  NFAIL=NFAIL+1 
BY  FTP*LAMFTP; 

ELSE 

(*  FAILURE  AFFECTS  DIU,  FTP  AND  ROOT  LINK  *) 

TRANTO  FWDIU=FWDIU-1,  PITSTK=PITSTK-1 , 

ROLSTK=ROLSTK-l,  YAWPED=YAWPED-1,  FTP=FTP-1,  ROOT=ROOT-l, 
NFAIL=NFAIL+1  BY  PITSTK* ROLSTK* YAWPED* 
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LAMFTP  / ( FWDIU**2  ) ; 


IF  FWDIU  > PITSTK  (*  AFFECTED  DIU  HAS  FAILED  PITSTK  *) 
TRANTO  FWDIU=FWDIU-1, 

ROLSTK=ROLSTK-l,  YAWPED=YAWPED-1,  FTP=FTP-1,  ROOT=ROOT-l, 
NFAIL=NFAIL+1 

BY  (FWDIU-PITSTK) *ROLSTK*YAWPED*  LAMFTP  / 

( FWDIU* *2  ) ; 

IF  FWDIU  > ROLSTK  (*  AFFECTED  DIU  HAS  FAILED  ROLSTK  *) 

TRANTO  FWD IU=FWD IU- 1 , PITSTK=PITSTK-1, 

YAWPED=YAWPED-1,  FTP=FTP-1,  ROOT=ROOT-l, 

NFAIL=NFAIL+1 

BY  PITSTK* (FWDIU-ROLSTK) *YAWPED*  LAMFTP  / 

( FWDIU* *2  ) ; 

IF  FWDIU  > YAWPED  (*  AFFECTED  DIU  HAS  FAILED  YAWPED  *) 

TRANTO  FWDIU=FWDIU-1,  PITSTK=PITSTK-1, 

ROLSTK=ROLSTK-l,  FTP=FTP-1,  ROOT=ROOT-1, 

NFAIL=NFAIL+1 

BY  PITSTK*  ROLSTK* (FWDIU- YAWPED ) * 

LAMFTP  / ( FWDIU* *2  ) ; 

IF  ROOT  > FWDIU 

(*  AFFECTED  CHANNEL  HAS  FAILED  DIU  *) 

TRANTO  FTP=FTP-1,  ROOT=ROOT-l,  NFAIL=NFAIL+1 
BY  (ROOT-FWDIU) * LAMFTP; 

IF  FTP  > ROOT  (*  AFFECTED  CHANNEL  HAS  FAILED  ROOT  *) 

TRANTO  FTP=FTP-1,  NFAIL=NFAIL+1 
BY  (FTP-ROOT)*  LAMFTP; 

ENDIF; 

ELSE 

IF  FTPREC  > 0 THEN 

(*  FTP  CHANNEL  RECOVERY  *) 

TRANTO  FTPREC=FTPREC-1  BY  < FTPMEAN,  FTP STD  >; 

(*  COINCIDENT  FAULT  *) 

TRANTO  FTP=FTP-1,  FTPREC=FTPREC+1,  ROOT=ROOT-l,  NFAIL=NFAIL+1 
BY  FTP * LAMFTP ; 

ENDIF; 

ENDIF; 


(*  BUS  AND  NETWORK  INTERFACE  FAILURES  *) 

IF  ROOT  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 AND  FTPREC  = 
THEN 

(*  FAILURE  AFFECTS  DIU  AND  ROOT  LINK  *) 

TRANTO  FWDIU=FWDIU-1,  PITSTK=PITSTK-1, 

ROLSTK=ROLSTK-l,  YAWPED=YAWPED-1 , ROOT=ROOT-l, 

NFAIL=NFAIL+1  BY  PITSTK*ROLSTK*YAWPED* 


( LAMROOT  + (LAMDIU  + LAMOD)  * DIUACT  ) / ( FWDIU**2  ) ; 

IF  FWDIU  > PITSTK  (*  AFFECTED  DIU  HAS  FAILED  PITSTK  *) 
TRANTO  FWD I U=FWD IU- 1 , 

ROLSTK=ROLSTK-l , YAWPED=YAWPED-1 , ROOT=ROOT-1, 
NFAIL=NFAIL+1 

BY  (FWDIU-PITSTK) * ROLSTK*  YAWPED*  ( LAMROOT  + 

(LAMDIU  + LAMOD)  * DIUACT  ) / ( FWDIU**2  ); 

IF  FWDIU  > ROLSTK  (*  AFFECTED  DIU  HAS  FAILED  ROLSTK  *) 
TRANTO  FWD I U=FWD I U- 1 , PITSTK=PITSTK-1, 

YAWPED=YAWPED-1,  ROOT=ROOT-l, 

NFAIL=NFAIL+1 

BY  PITSTK*  (FWDIU- ROLSTK) * YAWPED*  ( LAMROOT  + 

(LAMDIU  + LAMOD)  * DIUACT  ) / ( FWDIU**2  ); 

IF  FWDIU  > YAWPED  (*  AFFECTED  DIU  HAS  FAILED  YAWPED  *) 

TRANTO  FWD I U=F WD I U- 1 , PITSTK=PITSTK-1, 

ROLSTK=ROLSTK-l,  ROOT=ROOT-l, 

NFAIL=NFAIL+1 

BY  PITSTK*  ROLSTK*  ( FWDIU- YAWPED ) * 

( LAMROOT  + (LAMDIU  + LAMOD)  * DIUACT  ) / ( FWDIU**2  ) ; 

IF  ROOT  > FWDIU 

(*  AFFECTED  CHANNEL  HAS  FAILED  DIU  *) 

TRANTO  ROOT=ROOT-l,  NFAIL=NFAIL+1 
BY  (ROOT-FWDIU) * ( LAMROOT  + LAMOD*DIUACT  ) ; 

ENDIF; 


(***  ELECTRIC  POWER  DISTRIBUTION  FAILURES  ***) 

IF  FTP  > 0 AND  PITREC  = 0 AND  ROLREC  = 0 AND  YAWREC  = 0 AND  FTPREC  = 0 
THEN 

(*  FAILURE  AFFECTS  DIU,  FTP  AND  ROOT  LINK  *) 

TRANTO  FWDIU=FWDIU-1,  PITSTK=PITSTK-1, 

ROLSTK=ROLSTK- 1 , YAWPED=YAWPED-1,  FTP=FTP-1,  ROOT=ROOT-l, 
NFAIL=NFAIL+1  BY  PITSTK* ROLSTK* YAWPED* 

LAMEL  / ( FWDIU* *2  ); 

IF  FWDIU  > PITSTK  (*  AFFECTED  DIU  HAS  FAILED  PITSTK  *) 
TRANTO  FWDIU=FWDIU-1, 

ROLSTK=ROLSTK- 1 , YAWPED=YAWPED-1 , FTP=FTP-1,  ROOT=ROOT-l, 
NFAIL=NFAIL+1 

BY  (FWDIU-PITSTK) * ROLSTK* YAWPED*  LAMEL  / 

( FWDIU**2  ) ; 

IF  FWDIU  > ROLSTK  (*  AFFECTED  DIU  HAS  FAILED  ROLSTK  *) 

TRANTO  FWDIU=FWDIU-1,  PITSTK=PITSTK-1, 

YAWPED=YAWPED-I,  FTP=FTP-1,  ROOT=ROOT-l, 

NFAIL=NFAIL+1 

BY  PITSTK* (FWDIU-ROLSTK) *YAWPED*  LAMEL  / 

( FWDIU* *2  ) ; 
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END  IF; 


IF  FWDIU  > YAWPED  (*  AFFECTED  DIU  HAS  FAILED  YAWPED  *) 

TRANTO  FWDIU=FWDIU-1,  PITSTK=PITSTK-1, 

ROLSTK=ROLSTK-l , FTP=FTP-1,  ROOT=ROOT-l, 

NFAIL=NFAIL+1 

BY  PITSTK*  ROLSTK* (FWDIU-YAWPED) * 

LAMEL  / ( FWDIU**2  ); 


IF  ROOT  > FWDIU 

(*  AFFECTED  CHANNEL  HAS  FAILED  DIU  *) 


TRANTO  FTP=FTP-1,  ROOT=ROOT-l,  NFAIL=NFAIL+1 
BY  (ROOT-FWDIU) * LAMEL; 


IF  FTP  > ROOT  (*  AFFECTED  CHANNEL  HAS  FAILED  ROOT  *) 


TRANTO  FTP=FTP-1,  NFAIL=NFAIL+1 
BY  (FTP-ROOT)*  LAMEL; 
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(***  Mid  Area  Model  - Safety  Criteria  - Bus  Option 
(*  Group  A 

(* 


SPACE 


START 


DUMMY1 : 

0. 

■ If 

MIDDIU: 

0. 

• 4, 

(* 

MID  DIU  STATE  INDICATOR 

GYRO: 

0. 

•8, 

(* 

GYROS 

GYREC: 

0. 

• 2, 

<* 

GYRO  RECOVERY  INDICATOR 

ACCEL: 

0. 

• 8, 

(* 

ACCELEROMETERS 

ACCREC : 

0. 

■ 2, 

(* 

ACCEL  RECOVERY  INDICATOR 

CNDP : 

0. 

•4, 

(* 

CND  CHANNEL  STATE 

CNDV: 

0. 

• 4, 

(* 

CND  VALVE  STATE 

HYD: 

0. 

■2, 

(* 

HYDRAULIC  SYSTEM  STATE 

ELMC: 

0. 

•4, 

(* 

ELMC  STATE  INDICATOR 

NFAIL: 

0. 

• 4); 

(* 

NO.  OF  FAILED  ELEMENTS 

4* 

OO 

o 

8, 

Of  4 f 

4, 

2,  4,  0 ); 

PRUNEIF  NFAIL  > 2; 


DEATHIF  GYRO-GYREC  < 3 OR  ACCEL-ACCREC  < 3; 
DEATHIF  CNDV  = 0; 


LIST  = 2; 

TIME  = 3.0; 
PRUNE  = 1.0E-16; 
ECHO  = 0; 

POINTS  = 6; 


*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 


LAMGYRO  = 
LAMACC  = 
LAMNOD  = 
LAMDIU  = 
GYRMEAN  = 
GYRSTD  = 
ACCMEAN  = 
ACCSTD  = 


50.  OE-6; 
30. OE-6; 
15.0E-6; 
15.0E-6; 
3. OE-4; 
1.0E-4; 
3. OE-4; 
1.0E-4; 


(*  GYRO  FAILURE  RATE  *) 
(*  ACCELEROMETER  FAILURE  RATE  *) 
(*  NODE  FAILURE  RATE  - CONDITIONED  *) 
(*  DIU  FAILURE  RATE  - CONDITIONED  *) 
(*  RECOVERY  TIME  MEAN  *) 
(*  RECOVERY  TIME  STD  DEV  *) 
(*  ACC  RECOVERY  TIME  MEAN  *) 
(*  ACC  RECOVERY  TIME  STD  DEV  *) 


LAMC  = 50.0E-6;  (* 
LAMPOS  = 10.0E-6;  (* 
LAMV  = 15.0E-6;  (* 
VJAM  = 3 . 3333E-5;  (* 
LAMHYD  = 45.0E-6;  (* 


PROCESSOR  FAILURE  RATE  *) 
POSITION  SENSOR  FAILURE  RATE  *) 
VALVE  GROUP  FAILURE  RATE  *) 
ACTUATOR  JAM  FAILURE  FRACTION  *) 
HYDRAULIC  SYSTEM  FAIL  RATE  *) 


LAMPS 
LAMEL 
NWMEAN  = 
NWSTD 
LAMON 
LAMFTP  = 
LAMROOT  = 
LAMOD 
(*  DIUACT 


10. OE-6; 

50 . OE-6; 

3. OE-4; 

1 . OE-4; 

255. OE-6; 
200. OE-6; 

15. OE-6; 
127.5E-6; 

= 0.10;  *) 


(*  LOCAL  POWER  SUPPLY  - CONDITIONED  *) 


(*  ELMC  FAILURE  RATE  *) 

(*  NW  RECOVERY  TIME  MEAN  *) 

(*  NW  RECOVERY  TIME  STD  DEV  *) 

(*  OTHER  NODES  FAILURE  RATE  *) 

(*  FTP  CHANNEL  FAILURE  RATE  *) 

(*  BUS  INTERFACE  FAILURE  RATE  *) 

(*  OTHER  DIUS  ON  BUS  FAILURE  RATE  *) 

(*  DIU  ACTIVE  FAILURE  FRACTION  *) 
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(*  GYRO  SENSOR  FAILURES  AND  RECOVERIES  *) 

IF  GYRO  > 0 AND  GYREC  = 0 AND  ACCREC  = 0 THEN 

IF  GYRO  = 4 THEN  (*  EXHAUSTION  *) 

TRANTO  GYRO  = GYRO-1,  GYREC-GYREC+1,  NF  AI  L=NF  AI  L+ 1 

BY  GYRO*  LAMGYRO ; 

ELSE 

TRANTO  GYRO  = GYRO-1,  NF  AI L=NF AI L+ 1 
BY  GYRO*  LAMGYRO ; 

ENDIF; 

ENDIF; 


(*  ACCEL  SENSOR  FAILURES  AND  RECOVERIES  *) 


IF  ACCEL  > 0 AND  GYREC  = 0 AND  ACCREC  = 0 THEN 


IF  ACCEL  = 4 THEN  (*  EXHAUSTION  *) 

TRANTO  ACCEL  = ACCEL- 1,  ACCREC=ACCREC+1, 
BY  ACCEL* LAMACC; 


NFAIL=NFAIL+1 


TRANTO  ACCEL  = ACCEL-1,  NFAIL=NFAIL+1 
BY  ACCEL*LAMACC; 


ENDIF; 

ENDIF; 


(***  ACTUATOR  PROCESSOR  GROUP  FAILURE  TRANSITIONS  ***) 


IF  CNDP  > 0 THEN 

TRANTO  CNDP=CNDP-1,  NFAIL=NFAIL+1 

ENDIF; 


BY  2*CNDP* (LAMC  + LAMPOS) ; 


(***  VALVE  GROUP  FAILURES  ***) 


IF  CNDV  > 0 THEN 

IF  NFAIL  = 0 

TRANTO  CNDV=0,  NF AI L=NF AI L+l  BY  CNDV*VJAM*LAMV; 
TRANTO  CNDV=CNDV-1,  NFAIL=NFAIL+1  BY  CNDV* (1 . 0-VJAM) *LAMV; 

ENDIF; 


(*  HYDRAULIC  SYSTEM  FAILURES  *) 

IF  HYD  > 0 AND  (HYD-NFAIL  >=  0 ) THEN 

TRANTO  CNDV=CNDV-2 , HYD=HYD-1,  NFAIL=NFAIL+1 
BY  CNDV* (CNDV- 1)*LAMHYD  / ( 2*  (2*HYD-1)  ); 

IF  (2*HYD-CNDV)  > 0 

TRANTO  CNDV=CNDV-1,  HYD=HYD-1,  NF AI L=NF AI L+l 
BY  (2*HYD-CNDV)*2*CNDV*LAMHYD  / ( 2*  (2*HYD-1)  ); 


ENDIF; 


(2*HYD-CNDV)  > 1 

TRANTO  HYD=HYD-1,  NFAIL=NFAIL+1 
BY  (2*HYD-CNDV) * (2*HYD-CNDV-1) *LAMHYD 


/ ( 2*  (2*HYD-1)  ) ; 
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(*  MID  DIU  FAILURES  *) 

IF  MIDDIU  > 0 AND  GYREC  = 0 AND  ACCREC  = 0 THEN 

TRANTO  MIDDIU-MIDDIU-1,  GYRO=GYRO-2,  ACCEL=ACCEL-2,  CNDP=CNDP-1 
NFAIL=NFAIL+1  BY  GYRO*  (GYRO-1)*  ACCEL*  (ACCEL-1)*  CNDP* 

(LAMDIU  + LAMPS)/  ( 2*  (2*MIDDIU) * 

(2*MIDDIU-1) **2  *MIDDIU  ); 

IF  2*MIDDIU  - GYRO  >0  (*  DIU  HAS  FAILED  GYRO  *) 

TRANTO  MIDDIU=MIDDIU-1,  GYRO=GYRO-l,  ACCEL=ACCEL-2,  CNDP=CNDP-1 
NFAIL=NFAIL+ 1 BY  2*GYRO*  (2*MIDDIU-GYRO) * ACCEL*  (ACCEL-1)*  CNDP* 
(LAMDIU  + LAMPS)/  ( 2*  (2*MIDDIU) * 

(2*MIDDIU-1) **2  *MIDDIU  ); 

IF  2*MIDDIU  - ACCEL  >0  (*  DIU  HAS  FAILED  ACCELEROMETER  *) 

TRANTO  MIDD IU=MIDD IU- 1 , GYRO=GYRO-2,  ACCEL=ACCEL-1,  CNDP=CNDP-1 
NFAIL-NFAIL+1  BY  GYRO*  (GYRO-1)*  2*ACCEL*  (2*MIDDIU-ACCEL) * CNDP* 
(LAMDIU  + LAMPS)/  ( 2*  (2*MIDDIU) * 

(2*MIDDIU-1) **2  *MIDDIU  ); 

IF  MIDDIU  - CNDP  >0  (*  DIU  HAS  FAILED  CND  PROCESSOR  *) 

TRANTO  MI DD I U=MI DD IU- 1 , GYRO=GYRO-2/  ACCEL=ACCEL-2, 

BY/GYR0*  (GYRO-1)*  ACCEL*  (ACCEL-1)*  (MIDDIU-CNDP)  * 
(LAMDIU  + LAMPS)/  ( 2*  (2*MIDDIU)* 

(2*MIDDIU-1) **2  *MIDDIU  ); 

END IF; 


(*  BUS  CENTRAL  FAILURES  - NOT  COMMON  TO  FOR  MODEL  *) 

IF  MIDDIU  > 0 AND  GYREC  = 0 AND  ACCREC  = 0 THEN 

TRANTO  MIDDIU=MIDDIU-1,  GYRO=GYRO-2,  ACCEL=ACCEL-2 , CNDP=CNDP-1, 

NF A I L=NF A I L + 1 BY  GYRO*  (GYRO-1)*  ACCEL*  (ACCEL-1)*  CNDP* 

( LAMROOT+  (LAMOD) *DIUACT  ) / 

( 2*  (2*MIDDIU) * (2*MIDDIU-1) **2  *MIDDIU  ); 

IF  2*MIDDIU  - GYRO  >0  (*  DIU  HAS  FAILED  GYRO  *) 

TRANTO  MIDDIU=MIDDIU-1,  GYRO=GYRO-l,  ACCEL=ACCEL-2,  CNDP=CNDP-1 
NFAIL=NFAIL+1  BY  2*  GYRO*  (2*MIDDIU-GYRO) * ACCEL*  (ACCEL-1)*  ' 
CNDP*  ( LAMROOT+  (LAMOD) *DIUACT  ) / 

( 2*  (2*MIDDIU) * (2*MIDDIU-1)**2  *MIDDIU  ); 

IF  2*MIDDIU  - ACCEL  >0  (*  DIU  HAS  FAILED  ACCELEROMETER  *) 

TRANTO  MIDDIU=MIDDIU-1,  GYRO=GYRO-2,  ACCEL=ACCEL-1,  CUDP=CNDP-1 
NFAIL-NFAIL+1  BY  GYRO*  (GYRO-1)*  2*  ACCEL*  (2*MIDDIU-ACCEL) * 
CNDP*  ( LAMROOT+  (LAMOD) *DIUACT  ) / 

( 2*  (2*MIDDIU) * (2*MIDDIU-1 ) **2  *MIDDIU  ); 

IF  MIDDIU  - CNDP  >0  (*  DIU  HAS  FAILED  CND  PROCESSOR  *) 

TRANTO  MIDDIU=MIDDIU-1 , GYRO=GYRO-2,  ACCEL=ACCEL-2, 

NFAIL=NFAIL+1  BY  GYRO*  (GYRO-1)*  ACCEL*  (ACCEL-1)*  (MIDDIU-CNuP) * 
( LAMROOT+  (LAMOD) *DIUACT  ) / 
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END IF; 


( 2*  (2*MIDDIU) * (2*MIDDIU-1)**2  *MIDDIU  ); 


IF  ELMC 


END IF; 


(*  CENTRAL  FAILURES  - INCLUDES  ELEMENTS  COMMON  TO  FOR  MODEL  *) 

> 0 AND  GYREC  * 0 AND  ACCREC  = 0 THEN 

TRANTO  MIDDIU-MIDDIU-1,  GYRCW3YRO-2,  ACCEL=ACCEL-2,  CNDP=CNDP-1, 
ELMC=ELMC-1,  NFAIL=NFAIL+1  BY  GYRO*  (GYRO-1)*  ACCEL*  (ACCEL-1)*  CNDP* 
( LAMFTP  + LAMEL  ) / 

( 2*  (2*MIDDIU) * (2*MIDDIU-1) **2  *MIDDIU  ); 

IF  2*MIDDIU  - GYRO  >0  (*  DIU  HAS  FAILED  GYRO  *) 

TRANTO  MIDDIU=MIDDIU-1,  GYRO=GYRO- 1 , ACCEL=ACCEL-2,  CNDP=CNDP-1, 
ELMC=ELMC-1,  NFAIL=NFAIL+1  BY  2*  GYRO*  (2*MIDDIU-GYRO) * ACCEL* 
(ACCEL-1)*  CNDP*  ( LAMFTP  + LAMEL  ) / 

( 2*  (2*MIDDIU) * (2*MIDDIU-1) **2  *MIDDIU‘); 

IF  2*MIDDIU  - ACCEL  >0  (*  DIU  HAS  FAILED  ACCELEROMETER  *) 

TRANTO  MIDDIU=MIDDIU-1,  GYRO~GYRO-2,  ACCEL=ACCEL-1,  CNDP=CNDP-1, 
ELMC=ELMC-1,  NFAIL=NFAIL+1  BY  GYRO*  (GYRO-1)*  2*  ACCEL* 
(2*MIDDIU-ACCEL) * CNDP*  ( LAMFTP  + LAMEL  ) / 

( 2*  (2*MIDDIU) * (2*MIDDIU-1) **2  *MIDDIU  ); 

IF  MIDDIU  - CNDP  >0  (*  DIU  HAS  FAILED  CND  PROCESSOR  *) 

TRANTO  MIDDIU=MIDDIU-1,  GYRO=GYRO-2,  ACCEL=ACCEL-2,  ELMC=ELMC-1, 
NFAIL=NFAIL+1  BY  GYRO*  (GYRO-1)*  ACCEL*  (ACCEL-1)*  (MIDDIU-CNDP ) * 
( LAMFTP  + LAMEL  ) / 

( 2*  (2*MIDDIU) * (2*MIDDIU-1)**2  *MIDDIU  ); 

IF  ELMC  - MIDDIU  >0  (*  CHANNEL  HAS  FAILED  DIU  *) 

TRANTO  ELMC=ELMC-1,  NFAIL=NFAIL+1  BY  (ELMC -MIDDIU) *LAMEL; 
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(**★ 

(* 

<* 

Wing  and  Tail  Area 

Model  - Safety  Criteria  - Bus 
Group  A 

Option 

SPACE 

= ( DUMMY1: 

0..1, 

DUMMY2 : 

0..1, 

RWP 

0..4, 

(*  RW  CHANNEL  STATE 

*) 

RWV 

0..4, 

(*  RW  VALVE  STATE 

*) 

LWP 

0..4, 

(*  LW  CHANNEL  STATE 

*) 

LWV 

0..4, 

{*  LW  VALVE  STATE 

*) 

TLP 

0..4, 

(*  TL  CHANNEL  STATE 

*) 

TLV 

0..4, 

(*  TL  VALVE  STATE 

*) 

HYD 

0..2, 

(*  HYDRAULIC  SYSTEM  STATE 

*) 

BUS 

0..4, 

(*  CENTRAL  BUS  STATE 

*) 

NFAIL: 

0 . . 4 ) ; 

(*  NO.  OF  FAILED  ELEMENTS 

*) 

START  ^ 

- ( 0,  C 

r 4 f 

4,  4, 

4,  4,  4,  2,  4,  0 ) ; 

PRUNE IF 

NFAIL 

> 2; 

DEATHIF 

RWV  = 

0; 

DEATH IF 

LWV  = 

0; 

DEATHIF 

TLV  = 

0; 

LIST  = 2; 

TIME  = 3.0; 
PRUNE  = 1.0E-16; 
ECHO  = 0; 

POINTS  = 6; 


LAMC  = 50.0E-6;  (*  PROCESSOR  FAILURE  RATE  *) 

LAMPOS  = 10.0E-6;  (*  POSITION  SENSOR  FAILURE  RATE  *) 

LAMSD  = 20.0E-6;  (*  SERVODRIVE  GROUP  FAILURE  RATE  *) 

LAMV  = 15.0E-6;  (*  VALVE  GROUP  FAILURE  RATE  *) 

VJAM  = 3.3333E-5;  (*  ACTUATOR  JAM  FAILURE  FRACTION  *) 

LAMNODH  = 37.5E-6;  (*  NODE  FAILURE  RATE  - HARSH  *) 

LAMDIUH  = 37.5E-6;  (*  DIU  FAILURE  RATE  - HARSH  *) 

LAMHYD  = 45.0E-6;  (*  HYDRAULIC  SYSTEM  FAIL  RATE  *) 

LAMPSH  = 25.0E-6;  (*  LOCAL  POWER  SUPPLY  RATE  - HARSH  *) 

LAMEL  = 50.0E-6;  (*  ELMC  FAILURE  RATE  *) 

NWMEAN  = 3.0E-4;  (*  NW  RECOVERY  TIME  - MEAN  *) 

NWSTD  = 1.0E-4;  (*  NW  RECOVERY  TIME  - STD  DEV  *) 

LAMON  = 60.0E-6;  (*  OTHER  NODE  FAILURE  RATE  *) 

LAMOD  = 30.0E-6;  (*  OTHER  DIUS  ON  1 BUS  FAIL  RATE  *) 

LAMFTP  = 200.0E-6;  (*  FTP  CHANNEL  FAILURE  RATE  *) 

LAMROOT  » 15.0E-6;  (*  BUS  INTERFACE  FAILURE  RATE  *) 

(*  DIUACT  = 0.10;  *)  (*  DIU  ACTIVE  FAILURE  FRACTION  *) 
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(***  rw  PROCESSOR  GROUP  FAILURE  TRANSITIONS  ***) 

IF  RWP  > 0 THEN 

TRANTO  RWP=RWP - 1 , NFAIL=NFAIL+1  BY  2*RWP* (LAMC  + LAMPOS); 

ENDIF; 


(***  rw  VALVE  GROUP  FAILURES  ***) 

IF  RWV  > 0 THEN 

IF  NFAIL  = 0 

TRANTO  RWV=0,  NF A I L=NF AI L+ 1 BY  RWV*VJAM*LAMV; 
TRANTO  RWV=RWV-1,  NFAIL=NFAIL+1  BY  RWV* (1 . 0-VJAM) *LAMV ; 

ENDIF; 


(*  RW  DIU  FAILURES  *) 

IF  RWP  > 0 THEN 

TRANTO  RWP=RWP-1,  NFAIL=NFAIL+1  BY  RWP* (LAMDIUH* 
(1 . 0-DIUACT)  + LAMPSH) ; 

ENDIF; 


(***  LW  PROCESSOR  GROUP  FAILURE  TRANSITIONS  ***) 

IF  LWP  > 0 THEN 

TRANTO  LWP=LWP-1,  NFAIL=NFAIL+1  BY  2* LWP* (LAMC  + LAMPOS); 

ENDIF; 


(***  LW  VALVE  GROUP  FAILURES  ***) 

IF  LWV  > 0 THEN 

IF  NFAIL  = 0 

TRANTO  LWV=0,  NF AI L=NF AI L+ 1 BY  LWV*VJAM*LAMV; 
TRANTO  LWV=LWV-1,  NFAIL=NFAIL+1  BY  LWV* (1 . 0-VJAM) *LAMV; 

ENDIF; 


(*  LW  DIU  FAILURES  *) 

IF  LWP  > 0 THEN 

TRANTO  LWP=LWP-1,  NFAIL=NFAIL+1  BY  LWP* (LAMDIUH* 
(1. 0-DIUACT)  + LAMPSH); 

ENDIF; 


(***  TL  PROCESSOR  GROUP  FAILURE  TRANSITIONS  ***) 

IF  TLP  > 0 THEN 

TRANTO  TLP=TLP-1,  NFAIL=NFAIL+1  BY  2*TLP* (LAMC  + LAMPOS) ; 

ENDIF; 

(***  TL  VALVE  GROUP  FAILURES  ***) 


IF  TLV  > 0 THEN 

IF  NFAIL  = 0 

TRANTO  TLV=0 , NFAIL=NFAIL+1  BY  TLV*VJAM*LAMV ; 
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TRANTO  TLV=TLV- 1 , NFAIL=NFAIL+1  BY  TLV* (1 . 0-VJAM) *LAMV; 

ENDIF; 


(*  TL  DIU  FAILURES  *) 

IF  TLP  > 0 THEN 

TRANTO  TLP=TLP-1 , NFAIL=NFAIL+1  BY  TLP* (LAMDIUH* 
(1 . 0-DIUACT)  + LAMPSH) ; 

ENDIF; 


(*  HYDRAULIC  SYSTEM  FAILURES  *) 

IF  HYD  > 0 AND  (HYD-NFAIL  >=  0 ) THEN 

TRANTO  RWV=RWV-2,  LWV=LWV-2,  TLV=TLV-2,  HYD=HYD-1,  NFAIL=NFAIL+1 
BY  RWV* (RWV-1 ) *LWV*  (LWV-1) *TLV* (TLV-1 ) *LAMHYD  / 

( 2*  (2*HYD) **2  * (2*HYD-1) **3  ); 

IF  (2*HYD-RWV)  > 0 THEN 

TRANTO  RWV=RWV-1,  LWV=LWV-2,  TLV=TLV-2,  HYD=HYD-1,  NFAIL=NFAIL+1 
BY  (2*HYD-RWV) *2*RWV*LWV* (LWV-1) *TLV* (TLV-1) *LAMHYD  / 

( 2*  (2*HYD) **2  * (2*HYD-1 ) **3  ); 

ENDIF; 

IF  (2*HYD-LWV)  > 0 THEN 

TRANTO  RWV=RWV-2,  LWV=LWV-1,  TLV=TLV-2,  HYD=HYD-1 , NFAIL=NFAIL+1 
BY  RWV* (RWV-1)*  2*LWV* (2*HYD-LWV) * TLV* (TLV-1) *LAMHYD  / 

( 2*  (2*HYD) **2  * (2*HYD-1 ) **3  ); 

ENDIF; 

IF  (2*HYD-TLV)  > 0 THEN 

TRANTO  RWV=RWV-2,  LWV=LWV-2,  TLV=TLV-1,  HYD=HYD-1,  NFAIL=NFAIL+1 
BY  RWV* (RWV-1)*  LWV* (LWV-1)*  2*TLV* (2*HYD-TLV) *LAMHYD  / 

( 2*  (2*HYD) **2  * (2*HYD-1 ) **3  ); 

ENDIF; 

ENDIF; 


(****  BUS  CENTRAL  AND  ELECTRIC  POWER  DISTRIBUTION  ***) 

IF  BUS  > 0 THEN 

TRANTO  RWP=RWP-1,  LWP=LWP-1,  TLP=TLP-1,  BUS=BUS-1, 

NFAIL=NFAIL+1  BY  RWP*  LWP*  TLP*  (LAMROOT+LAMFTP+LAMEL+ 
(LAMDIUH+LAMOD)  * DIUACT)  / ( BUS**2)  ; 

IF  BUS  - RWP  > 0 

TRANTO  LWP=LWP-1,  TLP=TLP-1,  BUS=BUS-1, 

NFAIL=NFAIL+1  BY  (BUS-RWP)*  LWP*  TLP*  (LAMROOT+LAMFTP+LAMEL+ 
(LAMOD)  * DIUACT)  / ( BUS**2); 

IF  BUS  - LWP  > 0 

TRANTO  RWP=RWP-1,  TLP=TLP-1,  BUS=BUS-1, 

NFAIL=NFAIL+1  BY  RWP*  (BUS-LWP)*  TLP*  (LAMROOT+LAMFTP+LAMEL+ 
(LAMOD)  * DIUACT)  / ( BUS**2) ; 
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IF 


ENDIF; 


BUS  - TLP  > 0 

TRANTO  RWP=RWP-1,  LWP=LWP-1,  BUS=BUS- 
NFAIL=NFAIL+1  BY  RWP*  LWP*  (BUS-TLP)* 
(LAMOD)  * DIUACT)  / ( BUS**2) ; 


( LAMROOT+LAMFTP+LAMEL+ 
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APPENDIX  B 

DENET  SIMULATION  MODEL 


STVAX/BDSDOC/AHO/l/l 42—9 


BUSMESSAG 


DEFINITION  DEVM  BusMassag; 


EXPORT  BuaMessageType*,  MesaageType,  NodeConimandType, 

PortNaneType,  IOActivityChoice, 

PortStataType,  PortEnablaRagistarTypa, 
NodaMaasageConttandType, 

NodaMessageResponaeType,  D lUCcmmandType , 

NumberOfPorts  Par  Node , NumbarOfNodes, 
MakeNodeConfigurationCoiomand,  MakaMonitorCommand; 

CONST  NumbarOfNodes  - 18; 

NumberOfPortsPerNode  - 5; 

TYPE 

NodeCotnmandType  - (ChangePortEnabla,  Null); 

PortNameType  - [1  . . NumberOfPortsPerNode  ] ; 

Ports tataTypa  - {Enabled,  Disabled); 

PortEnab  leRagi  a ter  Type  - ARRAY  PortNameType  OF  Port  S tataTypa  ; 

NodaMessageCommandType  - RECORD 

CASE  Command  : NodeConimandType  OF 

ChangePortEnabla 

PortEnablaRegistar  : PortEnablaRagistarTypa;  | 

Null  : 

END; 

END; 

NodaMasaagaRasponaaTypa  - RECORD 

PortEnablaRegistar  : PortEnablaRagistarTypa; 

END; 

IQActivityChoice  « (Input,  Output,  Grouped); 

DIUCoamandType  - RECORD 

Activity  : IOActivityChoice; 

CommandNumbar  : INTEGER; 

END; 

MessageType  - (Nodalnput,  NodaOutput,  DlUInput,  DIUOutput); 

BusMassagaTypa  * ENTITY 

Address  : INTEGER; 

CASE  Massage  : MessageType  OF 

Nodalnput  : 

Input  : NodaMessageCommandType 

I NodaOutput  : 

Output  : NodeMessagaResponseType ; 

I DlUInput  : 

DlUCommand  : DIUCommandType; 

( DIUOutput: 

END; 
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(*.*t.**.*****»*«**********************************t*****"***"****t******) 

(*  Thi*  procedure  generates  a node  configurtion  command  so  that  it 

can  be  aant  to  the  network  to  modify  a node' a port  enable  regiatar.  ) 

PROCEDURE  Mak^od.ConfigurationCo«mand(Nod^.».on  | ^^laR.gi;ltBrTyI><l) 

: BusMassagaTypa; 

(****t****t*********t***^***^*********t**t**t**tt*t***t**tt*ttitttt****ttt*) 

(*  This  procadura  ganaratas  a noda  status  command  (i.a  null  command 
to  tha  noda)  to  ba  usad  by  tha  Natwork  Managar  to  collact  tha 
Natwork' s Status.  *) 

PROCEDURE  MakaMonitorCooanand  (NodaAddrass  : INTEGER) 

: BusMassagaTypa; 

f**************************************************************************1 


END  BusMassag. 
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BUSMESSAG 
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DEVM  BusMassag; 


EXPOSE 


(*********** ******************* ************************** **************) 

PROCEDURE  MakaNoda Con figuration Command (NodaAddrass  : INTEGER; 

Configuration  : PortEnablaRagistarTypa) 
: BusMes  aagaTypa ; 


VAR  Command  : BusMasaagaTypa; 
Portlndax  : PortNamaTypa; 


BEGIN 

NEW  (Command) ; 

Command A .Addrass  • ■ NodaAddrass; 

Comaand* .Mas saga  :■  Nodalnput; 

Command* . Input . Command  : ■ ChangaPortEnabla; 

FOR  Portlndax  1 TO  NumbarOfPortaParNoda  DO 

Commands  Input. PortEnablaRagis tar [Portlndax]  Configuration [Portlndax] 


END; 

RETURN  (Command) ; 

END  MakaNodaConfigurationCommand; 

(t********************************************************************^ 

PROCEDURE  MakaMon it or Command  (NodaAddrass  : INTEGER) 

: BusMes sagaTypa; 


VAR  Command  : BusMaa aagaTypa; 

BEGIN 

NEW  (Command) ; 

Command* .Address  NodaAddrass; 

Command A .Mas saga  :■  Nodalnput; 

Command* . Input . Command  : m Null ; 

RETURN  (Command) ; 

END  MakaMonitorCommand; 

(...*******«.**************«*******************‘***t*‘*****************) 


END; 


BEGIN 


END  BusMassag. 


TYPECONST 


DEFINITION  MODULE  TypeConst; 

FROM  BuaMessag  IMPORT  PortNameType,  NuoberOfNodaa,  NumberOfPortsParNode; 

EXPORT  QUALIFIED  NetworkElamentType,  Channel IDType,  PortArrayType, 
NodaRacordType , PortRacord,  NodaArrayType,  StatuaType, 
PortConfigurationType,  PortStatusRacord,  PortStatuaArray , 
NodeStatua Record,  Channels tat usRecord,  NodaStatua Array, 
ChannalStatua Array,  NumberOfNetworks , NuaberOflOSPer Channel; 

(*  These  declarations  will  need  to  be  aoved  elsewhere  whan 
a core  appropiate  home  has  bean  found  for  them.  *) 

CONST  NuaberOfGPCS  - 1; 

Number OfDIUS  - 4; 

NumberOfNetworks  - 2 ; 

NumbarOflOSPerChannel  - 3; 

TYPE  GPCAddressType  - (1  ..  NumbarOfGPCS] ; 

ChannallDType  - (A,  B,  C); 

DIUAddraaaTypa  - [1  ..  NumberOfDIUS] ; 

(********************♦*********♦*******************************************) 
TYPE  NetworkElamentType  - (GPC,  Node,  DIU,  None) ; 

NetworkEleaentRecord  - RECORD 

CASE  AdjacentElamant  : Networks  lament  Type  OF 
GPC: 

GPCAddresa  : INTEGER; 

Channel  : Channel ID Type; 

i Node: 

NodaNumber  : INTEGER; 

NodaAddresa  : INTEGER; 

Port  : PortNameType; 

l DIU: 

DIUAddreas  : INTEGER; 

| None: 


END ; 


END; 


PortRecord  - RECORD 

Elttnent  ; NetworkElementRecord; 


END; 

PortArrayTypo  - ARRAY  [1  ..  Huab*rOfPortaPerNod«]  OF  ttatworkElamantRacord; 
NodaRacordType  - RECORD 

Node Address  : INTEGER; 

Port  Array  : PortArrayType; 

END; 

NodeArrayTypa  - ARRAY  [1  . . Number OfN odes]  OF  NodaRacordType; 

(***************** *********t*******************************************) 

(*  The  types  pertain  to  the  Network  Manager  maintaining  the  status 
of  the  Network.  *) 


StatusType  - (Idle,  Active,  Failed); 


PortConfigurationTypa  - (Inboard,  Outboard); 
PortStatuaRacord  - RECORD 

CASE  Status  : Statu a Type  OF 
Active : 

Direction  : PortConfigurationType; 
J Idle,  Failed: 

END; 

END; 


PortStatuaArray  - ARRAY  [1  ..  NumberOfPortaPerNode]  OF  PortStatuaRacord; 

NodaStatuaRacord  - RECORD 

Address  : INTEGER; 

Status  : StatuaType; 

PortStatus  : PortStatuaArray; 


END; 


ChannalStatuaRacord  - RECORD 

GPCAddraas  : INTEGER;  (*GPCAddreasType; *) 
Channel ID  : Channel IDT ype; 

Status  : StatuaType; 


END; 

NodaS tatusAr ray  « ARRAY  (1  . . NumberOfNodes ] OF  NodaStatuaRacord; 
ChannelStatusArray  ™ ARRAY  Channel IDT ype  OF  ChannalStatuaRacord; 


END  TypeConat. 


CENTRALDB 
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DEFINITION  DEVM  CentralDB; 

FUCM  BusMessag  IMPORT  PortNaaeType,  NumberOfPortsPerNode,  Number  OfNodas; 

FROM  TypeConat  IMPORT  NodeRecordType,  NodaArrayTypa,  NumberOf Networks , 
NumberOf I OSPerChannel; 

EXPORT  IOSConnectionType , UpdateNodaData,  ReadNode Interconnect ions, 
FindNodaNumber,  FindlOSConnactions; 

TYPE  IOSConnactionRacord  - RECORD 

GPCAddrass  : INTEGER; 

HodaConnactadTo  : INTEGER; 


END; 

IOSConnact  ionTypa  - ARRAY  [1  . . NumberOf  I OSPerChannel]  OF  IOSConnactionRacord 

(*********** ********************************************* 

[*  This  procadura  will  updata  on  element  of  the  data  that  represents 
tha  in tar element  connaction  of  the  I/O  Network.  *) 

PROCEDURE  UpdataNodeData{NodeNumber  : INTEGER; 

NetworkID  : INTEGER; 

Data  : NodaRacordTypa) ; 

(***** *** ********************* ************************************* *^tAt 

(*  Th»  procadura  will  raturn  tha  intarnal  data  structure  that  each 
AIPS  noda  has  initializad  with  its  own  data.  *) 

PROCEDURE  RaadNodalntarConnactions  (NatworkID  • INTEGER; 

VAR  NodaConnactions  : NodaArrayTypa); 

(*********** ************ ************ ****************** ********************** 

{*  This  procadura  will  saarch  tha  Cantral  Databasa  for  a noda  with 
"Address”  as  its  noda  addrass  and  raturn  its  noda  number. 

BEWARE : No  chack  is  dona  to  see  if  tha  addrass  given  corassponda 
to  an  addrass  on  your  network.  If  an  addrass  is  given  that 
is  not  on  your  network,  than  the  wrong  number  will  be  retruned.  *> 

PROCEDURE  FindNodaNumber (Address  : INTEGER)  : INTEGER; 

(★A********************************  **  * **********  ***  ************************* 

(*  This  procedure  will  saarch  the  Central  Databasa  an  raturn  all  tha 
IOS  connections  for  a tha  indicated  network.  An  IOS  which  is  not 
installed  will  have  a zero  ID.  *) 

PROCEDURE  FindlOSConnactions {NatworkID  : INTEGER; 

VAR  ConnectionArray  : IOSConnact ionTypa) ; 

(********t*t**********************tt*****************ikJr****t***************) 

TYPE  NatworkDascriptionTypa  - ARRAY  {I  ..  Number OfNatworks 3 OF  NodaArrayTypa; 

VAR  NetworkDescription  : NatworkDascriptionTypa; 

END  CentralDB. 
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CENTRALDB 


DEVM  CentralDB; 


FROM  BusMessag  IMPORT  PortNameType,  NumberOfPortaPerNode,  NumberOfNodas; 

FROM  TypeConst  IMPORT  NodaRecor dType , NetworkElementTypa,  ChannellDType, 

NodaArrayType,  Number OfNetworks , NuaberOf IOSPerChannel; 


EXPOSE 

(****4*********** **** ************************** *********************** *j 

PROCEDURE  UpdataNodaData  (NodeNumber  : INTEGER; 

NatworkID  : INTEGER; 

Data  : NodaRecordType) ; 

VAR  Portlndax  : PortNameType; 

Nodalndax  : INTEGER; 

Curran tNode I ndax  : INTEGER; 

Curran tNoda  : INTEGER; 


BEGIN 

WITH  NetworkDeacription (NatworkID] [NodaNumbar)  DO 
NodaAddraas  : - Data .NodaAddrasa; 

FOR  Portlndax  :■  1 TO  NumberOfPortsParNode  DO 

CASE  Data  .PortArray  [Portlndax]  .Ad jacantElamant  OF 
GPC : 


PortArray (Portlndax] .Ad jacantElamant  GPC; 

PortArray [Portlndax] .GPCAddress  Data. PortArray  (Portlndax]  .GPCAddrass; 

PortArray (Portlndax] .Channal  Data. PortArray (Portlndax] .Channel; 

| Noda: 

PortArray (Portlndax] .Ad jacantElamant  Noda; 

PortArray (Portlndax] .NodaAddrasa  Data. PortArray (Portlndax] .NodaAddraas 

PortArray (Portlndax] .Port  :■  Data . PortArray (Portlndax] .Port; 

I DIU: 

PortArray (Portlndax] .Ad jacantElamant  :«  DIU; 

PortArray [Port Index] .DIUAddrass  :«  Data. PortArray [Portlndax] .DIUAddrass; 

! Nona : 

PortArray [Port Indax] .Ad jacantElamant  Nona; 

END; 

END; 

END; 

(*  Dua  to  tha  natura  of  this  DENET  solution,  the  AIPS  noda  numbers 
of  AIPS  adjacent  nodes  cannot  be  sat  whan  this  procedure 
is  called.  To  solve  this  problem,  tha  new  information  is  entered, 

(sea  above  for  loop)  tha  database  will  be  searched  and 
correct  noda  numbers  entered.  *) 

FOR  Curran tNode Index  1 TO  NumberOfNodas  DO 

CurrentNode  NetworkDescription (NatworkID] [ Cur rantNode Indax] . 

NodeAddr ass; 

FOR  Nodalndax  1 TO  NumberOfNodas  DO 
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WITH  NetworkDescription (NatworkID] [Nodalndax]  DO 
IF  {NodeAddress  <>  CurrentNode)  THEN 


FOR  Portlndax  1 TO  NumbarOfPortsParNoda  DO 

IF  (PortArray  [Portlndax]  . AdjacantElaoant  - 

Noda)  AND  (PortArray [Portlndax] .NodaAddraas 
- CurrantNode)  THEN 

PortArray  (Port Indax]  .NodaNumber  :* 

Cu rran tNoda I nda x ; 


END  ; 


END; 


END; 


END; 


END; 


END; 


END  UpdataNodaData; 


PROCEDURE  RaadHoda Interconnections  (N»tworkID 

VAR  NodaConnactiona 


INTEGER; 
NodaArrayTypa) ; 


VAR  Noda  Indax  : INTEGER; 

Port Indax  : PortNamaTypa; 


BEGIN 

FOR  Noda  Indax 


1 TO  NumbarOfNodaa  DO 


NodaConnactiona [Nodalndax] .NodaAddraas 

NatworkDaacription [NatworkID]  [Nodalndax]  .NodaAddraas, 

FOR  Port Indax  1 TO  NumbarOfPortsParNoda  DO 

WITH  NetworkDescription[NotworkIDl [Nodelndex] . PortArray [Portlndax]  DO 
CASE  AdjacantElamant  OF 


NodaConnactiona [Nodalndax] .PortArray [Portlndax] . 
AdjacantElaoant  GPC; 

NodaConnactiona [Nodalndax] .PortArray [Portlndax] . 

GPCAddrasa  !*  GPCAddrass; 

NodaConnactiona [Nodalndax] .PortArray [Portlndax] . 
Channal  :*  Channai; 


| Noda: 

NodaConnactiona [Nodalndax] .PortArray [Portlndax] . 
AdjacantE lament  Noda; 

NodaConnactiona [Nodalndax] .PortArray [Portlndax] . 

NodaNumber  : ■ NodaNumber ; 

NodaConnactiona [Nodalndax] .PortArray [Portlndax] . 

NodaAddraas  :«  NodaAddraas; 

NodaConnactiona [Nodalndax] .PortArray [Portlndax] . 

Port  :•  Port; 


| DIU: 

HodeConnections [Nodelndex] .PortArray [Portlndax] . 
AdjacantE lament  :«  DIU; 

NodaConnactiona [Nodalndax) .PortArray [Portlndax] . 
DIU  Address  :■  DIUAddraas; 
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I None: 


NodeConnect ions (Node Index] .PortAr ray [Port Index] . 
Ad j ace ntE lament  None; 


END; 


END; 


END; 


END; 

END  ReadNode Interconnect ions; 

(************* ******************t**************************************j 

PROCEDURE  FindNodeNumber (Address  : INTEGER)  : INTEGER; 

VAR  Networklndex  : INTEGER; 

Node  Index  : INTEGER; 

BEGIN 

FOR  Networklndex  1 TO  NumbarOfNetworka  DO 

FOR  Nodeindex  :■  1 TO  NuaberOfNodes  DO 

IF  NetworkDescription [Networklndex] [Nodeindex] .NodeAddress 
“ Address  THEN 

RETURN  (Node Index) ; 

END; 

END; 

END; 


RETURN  (0) ; 

END  FindNodeNumber; 

(***********************  o**t**********t******************ttt***tt**t**j 

PROCEDURE  FindlOSConnections {NetworkID  : INTEGER; 

VAR  Connect ionArr ay  : IOSConnectionType) ; 

VAR  NodeNumber  : INTEGER; 

Counter  : INTEGER; 

Index  : INTEGER; 

Port Index  : PortNameType; 


BEGIN 

Counter  1; 

NodeNumber  : * 1 ; 

WHILE  NodeNumber  <-  NumberOfNodes  DO 

WITH  NetworkDescription [NetworkID] [NodeNumber]  DO 

FOR  Portlndex  1 TO  NumberOfPortsPerNode  DO 

IF  PortArray [Portlndex] . AdjacentElement  - GPC  THEN 

Connect ionAr ray [Counter] .GPCAddress  PortArray (Port I ndex ] . 

GPCAddreas ; 

Connect lonArray [Counter] .NodeConnectedTo  NodeNumber* 
Counter  ;«  Counter  + 1; 


END; 
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END; 


NodaNumbar  :■  NodaNumbar  + 1; 

END; 

END; 

(*  sat  elements  in  connection  array  who  do  not  have  IOS's 
connactad  to  them  to  0.  *) 

IF  Counter  <*  NumbarOf  IOSParChannal  THEN 

FOR  Indax  :*  Counter  TO  NumbarOf IOSParChannel  DO 

Connact ionAr ray [Indax] .GPCAddrass  : ■ 0; 


END; 


END; 

END  FindlOSConnections; 


t****,^*..****o**«*..**.********************“**“*************) 


END; 


EVENT  Dummy  : INTEGER; 


VAR  Port Indax  : PortNamaTypa ; 

Nodalndax  • INTEGER; 

Natworblndax  : INTEGER; 


{******** 

BEGIN 


t*******************************"********************************1 


(*  Initialize  the  Network  Description  so  that  all  nodes  are 
connected  to  no  elements  as  an  initial  state.  ) 

FOR  Networklndex  1 TO  NumberOfNetworks  DO 

FOR  Nodeindex  1 TO  NomberOfNodes  DO 

NetworkDescription [Networklndex) [Nodeindex]  .NodaAddress  Nodeindex; 

FOR  Portlndex  1 TO  NumberOfPortsPerNode  DO 

NetworkDescription [Networklndex] [Nodalndax] .Port Array [Portlndex] .AdjacentElement 

:»  Nona; 


END; 

END; 

END; 

LOOP 

WAITUNTIL  EVENT 
Dummy: ; 

END; 


END; 

END  CentralDB. 
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AIPSNODE 


DEVM  AIPSNode; 


FROM  BusMessag  REACH  BusMesaageType*; 

FROM  BusMessag  IMPORT  PortEnableRegistarType , PortNameType, 

NumberOfPortsPerNode,  PortStateType,  MasaageType, 
NodeCommandType ; 

FROM  CantralDB  IMPORT  UpdateNodeData; 

FROM  TypaConat  IMPORT  PortArrayType,  PortRacord,  NetworkElenentType, 
HodaRacordTypa,  ChannallDTypa; 

(*  Thia  will  allow  tha  initialisation  of  tha  databaaa  that  will  ba 
usad  by  tha  network  managar.  Tha  array  imported  is  from  tha 
DENET  Node  Managar  module,  and  it  describes  tha  interconnections 
of  each  instance  of  tha  DENET  nodes.  *) 

FROM  NodaM  IMPORT  FindConnector; 


INPUTS  _ 

EVENT  NodeCcmmandFrame  : BusMaa  saga  Type; 
gAsot  • BOOLEAN; 


PARA  NetworkID 
NodaNumbar 
Saquan carTimaLowar 

SaquancarTimaUppar 

InitialConfiguration 


INTEGER; 

INTEGER; 

REAL; 

REAL; 

ARRAY  (1  . . NumberOfPortsPerNode]  OF  BOOLEAN 


END; 


OUTPUTS 

VAR  NodaRasponsaFrama  : BusMassagaTypa; 


END; 


VAR  MasaagaFromNatwork 
PortEnablaRegister 
Port 

NodeData 
Portlndax 
Adjacent  Node  ID 
Ad  j ac  an tNodeTypa 
InPort 
OutPort 


BusMassagaTypa; 
PortEnableRegistarType; 
PortNameType; 
NodaRacordTypa ; 
PortNameType; 

INTEGER; 

INTEGER; 

INTEGER; 

INTEGER; 


/♦a************************************************ ************************* 
(*  This  procedure  is  responsible  for  transmitting  traffic  to  tha 
network  from  tha  sequencer. 

It  consults  tha  port  activity  register  to  determine  if  a port  is 
enabled,  if  it  is,  the  massage  is  transmitted  to  tha  network 
from  that  port.  *) 


PROCEDURE  Transmit (Massage  : BusMassagaTypa); 


VAR  Stream  : INTEGER; 
Sequence rTime  : REAL; 
Portlndex  : PortNameType; 


BEGIN 

Stream  1; 

(*  Compute  the  Sequencer  Response  Time  for  this  message.  *) 
SequencerTima  Random  (Stream,  SaquancarTimeLowar,  SaquancarTimaUppar ) ; 

FOR  Portlndax  1 TO  OutArcs  DO 

(*  Check  to  see  if  this  port  is  enabled.  *) 

IF  PortEnableRegister (Portlndax]  “ Enabled  THEN 


AFTER  SequencarTime  outport  [Portlndex] A .NodeResponseFraae  <-  Massage 


END; 


END; 


END  Transmit ; 

(******************************♦******* * to*  *************  ********t*********j 
(*  This  procadura  is  responsible  for  processing  network  traffic  received 
on  a port  of  this  node  and  formatting  a response  for  transmission 
if  one  is  required.  *) 

PROCEDURE  Sequencer  (Command  : BusMessageType) ; 

VAR  CnmmandRespopseFrame  : BusMessageType; 

Port Index  : PortNameType; 


BEGIN 

(*  Begin  processing  message.  *) 

(*  Check  to  see  if  message  is  addressed  to  this  node.  *) 

IF  Command A. Address  - MyNodelD  THEN 

(*  Execute  the  command.  *) 

CASE  Command A .Message  OF 

Nodeinput  : (*  This  is  a command  from  the 

Network  Manager.  *) 

(*  Determine  what  the  command  is.  *) 

CASE  Command A . Input . Command  OF 

ChangePortEnable  : 

FOR  Portlndex  1 TO  NumberOfPortsPerNode  DO 

PortEnableRegister [Port Index] 

Command A . Input .PortEnableRegister [Portlndex] ; 


END;  | 

Null:  (*  This  is  a do  nothing  command.  *} 


END; 

NEW  ( Comma ndResponseFrame) ; 

(*  Format  the  response  message.  *) 

WITH  CommandReaponseFrameA  DO 

Address  MyNodelD; 

Message  :«  NodeOutput; 

FOR  Portlndex  I TO  NumberOfPortsPerNode  DO 

Output . PortEnableRegister [Portlndex]  : - 
PortEnableRegister [Portlndex] ; 


END; 


END; 


(*  Transmit  the  Node  Resposne  to  the  Network.  *) 
Transmit (CommandResponseFrame) ; 

ELSE  (*  No  node  output  message  will  ever  be  addressed 
to  a node.  *) 

END; 


ELSE 
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END; 


END  Sequencer; 

t*************************************************************************^ 

BEGIN 

(*  Initialize  Port  Array  variable  to  all  porta  having  no  connection. 

The  InitializeDB  EVENT  will  fill  with  the  proper  data.  *) 

FOR  Port  1 TO  NunberOfPortsPerNode  DO 

NodeData.PortArray  [Port]  . Ad jacentE lament  :*  None; 


END; 

(*  Initialize  the  Database  for  the  Network  Manager  that 
describes  the  network  interconnections  for  this  node.  ) 

NodaData . NodeAddress  MyNodelD; 


FOR  Port  1 TO  OutArcs  DO 


Ad jacentNode ID  GetOutNode (Port) ; 

IF  CheckNodeType  (AdjacentNodelD,  "IOS" , TRUE)  THEN 


NodeData . PortArray [Port) . Ad  jacentElenent 
NodeData.PortArray [Port] .GPCAddresa 
NodeData . PortArray ( Port ] . Channel 


GPC; 

;»  AdjacentNodelD; 
A; 


ELS IF  CheckNodeType (AdjacentNodelD,  "AIPSNode",  TRUE)  THEN 


NodeData.PortArray [Port] . Ad jacentEleoent  Node; 

NodeData. PortArray [Port] .NodeAddress  •“  AdjacentNodelD, 

Get InOutPort (AdjacentNodelD,  MyNodelD,  OutPort,  InPort); 
NodeData.PortArray [Port] .Port  :*  OutPort; 


ELSIF  CheckNodeType  (AdjacentNodelD,  "DID" , TRUE)  THEN 


NodeData . PortArray [ Port ] . Ad jacentElement 
NodeData.PortArray [Port] .DIUAddress 


DIU; 

AdjacentNodelD ; 


ELSE 

WriteString (ParamOut,  "invalid  node" ) ; 
WriteLn (ParamOut) ; 


END; 


END; 

(*  Send  the  data  to  the  database.  *) 

UpdateNodeData (NodeNumber , NetworkID,  NodeData); 

(*  Load  port  enable  register  with  intial  configuration.  *) 
FOR  Portlndex  1 TO  Number OfPort a PerNode  DO 

IF  InitialConf igur at ion [Portlndex]  THEN 

PortEnableRegister [Portlndex]  Enabled; 

ELSE 

PortEnableRegister [Portlndex]  Disabled; 


END; 


END; 


ft********** 


*,,,«***«*.**********^>*********‘*************t*****************, 
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LOOP 


WAITUNTIL  EVENT 

NodeCamaandFrame : 

MessageFromNatwork  ActivePortA .NodeCommandFrame; 

(*  First  check  to  see  if  this  port  is  enabled,  if  so 
than  sand  traffic  to  othar  ports  on  this  node. 

A digrassion  from  the  A IPS  Network  Noda  has  baan 
takan  at  this  point  in  tha  implementation. 

Tha  traffic  is  only  aant  to  tha  ports  on  this  noda 
that  ara  a nab lad . This  shifts  tha  responsibility  of 
tha  port  to  check  to  sea  if  it  is  enabled  before 
transmitting,  to  tha  sender  of  tha  traffic.  *) 

(*  Check  to  see  if  the  port  tha  traffic  is  received  on 
is  enabled.  *) 

IF  PortEnableRagister (ActivaPort A . index]  - Enabled  THEN 

(*  Sand  traffics  to  all  othar  ports  on  this  noda.  *) 
FOR  Port  :■  1 TO  OutArcs  DO 

(*  Do  not  retransmit  on  port  which  traffic 
was  raciavad  *) 

IF  Ac tivePortA. index  <>  INTEGER (Port)  THEN 

(*  Transmit  message  back  to  tha  natwork 
only  if  the  port  is  enabled.  *) 

IF  PortEnableRagister [Port]  - Enabled  THEN 

NOW  outport (Port ] A .NodaResponseFrame  <- 
Mas sageFrooNetwork; 


END; 


END; 


END; 

END; 

(*  Sand  massage  to  Sequencer  for  Processing.  *) 

Sequencer ( Mas sagaFromNet work) ; 

( Reset: 

(*  Reload  port  enable  register  with  intial  configuration. 
FOR  Portlndex  :■  1 TO  NumberOfPortsParNode  DO 

IF  InitialConfiguration [Portlndex]  THEN 

PortEnableRegister [Portlndex]  Enabled; 

ELSE 

PortEnableRagister [Portlndex]  : - Disabled; 

END; 

END; 


END; 

END; 

END  AIPSNode. 
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DIU 


DEVM  DIU; 


FROM  BusMessag  REACH  BusMessageType*; 

FROM  BusMesaag  IMPORT  MeaaageType,  DIUCoomandType,  IOActivityChoice; 

INPUTS 

EVENT 

D IUCommandFrame  : BusMessageType; 

PARA  OverheadTiae  : REAL; 

CcmmandTimes  : ARRAY [1  . . 3]  OF  REAL; 

END; 

OUTPUTS 

VAR  D IURespons  eFrame  : BusMessageType; 

END; 

VAR  Command  : BusMessageType; 

Response  : BusMessageType; 

DIUComputeTime  : REAL; 

DIUEndTransmiasionTime  : REAL; 

BEGIN 

LOOP 

WAITUNTIL  EVENT 

DIUCommandFrama : 

Command  ActivaPortA .DIUCommandFrama; 

IF  Command*  .Address  - MyNodalD  THEN 

WITH  Command*  .DlUCommand  DO 

IF  Activity  - Input  THEN 

DIUComputeTime  :■  CommandTimas  [ CommandNumbar  ] ; 

ELSIF  Activity  =-  Output  THEN 

DIUComputeTime  : - 0.0; 

ELSE  (*  Actvity  * Grouped  *) 

DIUComputeTime  : - CommandTimaa  [CommandNumbar] ; 

END; 

END; 

IF  Command* . DlUCommand . Activity  o Output  THEN  (*  no  response  for  a write  *) 

NEW (Response) ; 

WITH  Response*  DO 

Address  MyNodelD; 

Message  :«  DIUOutput; 

END; 

DIUEndTransmis  s i onT ime  DIUComputeTime  + OverheadTime 

+ Random (1,  0.0,  0.000010); 

AFTER  DIUEndTransmissionTime  outport [ 1] * .DIUResponseFrame  <-  Response; 
END; 

END; 
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END; 

END; 

END  DIU. 
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IOS 
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DEFINITION  DEVM  IOS; 


FROM  BusMaaaag  REACH  BusMassagaTypa*; 

FROM  TypaConst  IMPORT  NumbarOf IOSParChannal,  NumbarOfNatworks; 

EXPORT  IOSRacordTypa,  IOSRacordTypaPointar,  ChainTypa*, 

TimaOut IndicatorTypa,  TranaactionQuauaTypa r 
TranaactionTypa* , InputFramaQuauaTypa  , 

InputFramaTypa* , Chains tatusData*,  TranaactionTurnAroundTiaa; 
TYPE  IOSRacordTypa  * RECORD 

NatvorkID  ; INTEGER; 

ICSID  : INTEGER; 

Humbar  : INTEGER; 


END; 

IOSRacordTypaPointar  - POINTER  TO  IOSRacordTypa; 

TimaOut  Indicator! ypa  - (NormalComplation,  TimadOut) ; 

TranaactionTypa  • ENTITY 

Idantifiar  : INTEGER; 

TimaOut Valua  : REAL; 

OutputFrama  : BuaMaaaagaTypa; 


END; 


TranaactionQuauaTypa  - QUEUE  OF  TranaactionTypa; 

ChainTypa  - ENTITY 

Chainldantifiar  : INTEGER; 

NuabarOf  Transact  ions  : INTEGER; 

NatworkToBaExacutadOn  : INTEGER; 

TranaactionQuaua  : TranaactionQuauaTypa; 

FramaCount  * INTEGER; 

END; 

InputFramaTypa  * ENTITY 

Tranaactionldantif iar  : INTEGER; 

MaaaagaAddrass  ; INTEGER; 

CASE  TransactionTimaOut Indicator  ; TimaOut I ndicatorTypa  OF 
NormalComplation  : 

InputFrama  : BuaMaaaagaTypa; 

| TimadOut  : 


END; 


END; 

InputFramaQuauaTypa  “ QUEUE  OF  InputFramaTypa; 

ChainStatusData  - ENTITY 

ChainTiaaOutlndicator  : TimaOut Indi cat orTypa; 

Al  IF  ail ad  : BOOLEAN; 

AnyFailad  : BOOLEAN; 

InputFramaQuaua  : InputFramaQuauaTypa; 


END; 


CONST  TransactionTurnAroundTima  - 0.000010; 


END  IOS. 
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DEVM  I OS; 


FROM  BusMassag  REACH  BusMassagaTypa*; 

FROM  BusMassag  IMPORT  PortNaaaTypa,  MassagaTypa,  IOActivityChoica, 
NodeCommandType , NumbarOfPortaParNoda; 

FROH  Controls  REACH  SystamProba,  NuabarOfProbas; 

FROM  Sanddata  IMPORT  WritaDataElaoantTypa,  DataZleoentType , 

FraquancyTypa,  CyclicDataTypa,  CyclicVariationTypa, 
NonCyclicVariationTypa,  ChainStataType; 


INPUTS 

EVENT  InputTransaction 
ChainToProcass 
StopChain 
Rasat 

ProbaRasat 


BusMassagaTypa ; 

ChainTypa; 

BOOLEAN; 

BOOLEAN; 

BOOLEAN; 


PARA  NatworkID 
RootNodalD 
IOSarvicalD 
NodaCommandB i ts  OnBua 
NodaRasponsaB i t s OnBua 
DIUIBitsOnBus 
ApplicationTranamitBits 
ApplicationRasponsaBits 
ProbaNumbar 


INTEGER; 

INTEGER; 

INTEGER; 

REAL; 

REAL; 

REAL; 

ARRAY [1  . . 3] , (0  ..  9]  OF  REAL; 
ARRAY (1  ..3],  (0  ..  9]  OF  REAL; 
INTEGER; 


END; 


OUTPUTS 


VAR  OutputTraa section  : BusMassagaTypa; 
IOChainRaaponaa  : ChainStatuaData; 
ChainFiniahad  : BOOLEAN; 

END; 

EVENT 

EndlOActivity  : BOOLEAN; 

Transact ionTimaOut  : BOOLEAN; 
DIUWrittan  : BOOLEAN; 


CONST  DataExchangaQuantity  » 2.0;  {*  bytes  par  exchange  *) 

TranaactionTurnAroundTima  - 0.000010; 

Max_Tranaact ions InChain  - 10; 


VAR  ChainUndarExacution 

Transact ion UnderExa cut ion 

RasponsaChain 

Natworklnput 

BitTimaForRaaponsa 

NumbarOf Transactions 

Transact ionTinaOutNotica 

NatworkPort 

lOSarvicaPort 

TaapTiaa 

Start IODataElamant 

EndlODataElamant 

ChainStatus 


ChainTypa; 
TransactionType ; 
Chains tat usData ; 
InputFrameTypa ; 
REAL; 

INTEGER; 

EventPointer; 

INTEGER; 

INTEGER; 

REAL; 

DataEl ament Type ; 
DataElamantTypa; 
ChainStataType; 


^********t******** *tt*****t ***************** ***t********t ****************** j 


PROCEDURE  ComputeTransmissionBitTime (Transaction  : TransactionType; 

Chain ID  : INTEGER)  : REAL; 


VAR  BitTime  : REAL; 
BEGIN 
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WITH  Transaction*  DO 

CASE  OutputFrame* .Mas saga  OF 
Nodelnput : 

BitTime  : - NodeConmandBitsOnBus; 

| DlUInput: 

IF  OutputFrame*  .DIUConmand.  Activity  o Input  THEN 

BitTim*  ApplicationTransaitBit* [ChainID,  (Idantifiar  MOD  MaxJTranaactiona InChain) ] ; 

ELSE 

BitTima  DIUIBitaOnBus ; 

END; 

END ; 

END; 

RETURN  (BitTima); 

END  ComputaTransmissionBitTime; 

(************************ ****** t**tt***************************************) 

PROCEDURE  ComputaRaaponsaBitTima (Transaction  : TransactionTypa; 

ChainID  : INTEGER)  : REAL; 


VAR  BitTima  : REAL; 

BEGIN 

WITH  Transaction*  DO 

CASE  OutputFrama* .Massaga  OF 
Node Input: 

BitTima  NodeRasponseBitsOnBus; 

| DlUInput: 

BitTima  :*  ApplicationRasponsaBits [ChainID,  (Idantifiar  MOD  Max_Transactions InChain) ] , 

END; 


END; 


RETURN (BitTima); 


END  ComputaRaaponsaBitTima; 

<**************************************************************************) 
(*  This  procadura  taXas  tha  next  transaction  from  tha  Chain  Currently 

Executing  and  sands  it  to  tha  netuorfc.  It  also  dacremanta  tha 
transactions  laft  to  execute  for  this  chain  counter,  and  schedules 
the  timeout  event  for  this  transaction.  *) 


PROCEDURE  ProcassTransaction (PreviouaTransaction  : 

Previous I nputFrama  : 
Chain  : 
VAR  Transact ionExecuting  : 
VAR  TransactionsLeftToExecute  : 
VAR  ResponseBitTime 


BOOLEAN; 
InputFramaTypa ; 
ChainType; 
TransactionTypa; 
INTEGER; 

REAL); 


VAR  NaxtMassagaBitTime  : REAL; 
TransactionOutputTime  : REAL; 
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BEGIN 


(*  Calculate  the  bits  on  the  bus  time  for  the  previous  transaction.  *) 

IF  Previous Transaction  THEN 

{*  Compute  the  next  transaction,  send  it  to  the  network  and 
schedule  its  timeout  event.  *) 

TransactionExecuting  : - QSucc (Trans act ionExecuting,  ChainA . Tr ansae tionQueue) ; 
(*  Bit  Time  to  transmit  the  next  message.  *) 

NextMessageBitTime  : - ComputeTransmissionBitTime  (TransactionExecuting, 

(ChainA . Chainldentif ier  MOD  4) ) ; 

Tran sactionOutput Time  ResponseBitTime  + TransactionTurnAroundTime  + 

NextMessageBitTime; 


ELSE 


(*  Compute  the  next  transaction,  send  it  to  the  network  and 
schedule  its  timeout  event.  *) 

TransactionExecuting  : - FirstQ (ChainA . Tran sac tionQueue) ; 
NextMessageBitTime  : - ComputeTransmissionBitTime (TransactionExecuting, 

(ChainA. Chainldentif ier  MOD  4)); 
TransactionOutputTime  NextMessageBitTime; 


END; 


(*  Decrement  transactions  left  to  process  counter.  *) 

TransactionsLeftToExecute  TransactionsLef tToExecute  - 1; 

WITH  Transact ionExecutingA  DO 

REPORT  "%d"  Identifier  TAGGED  "Transaction  started  Execution."; 

AFTER  TransactionOutputTime  outport [NetworkPort] A . OutputTransaction  <-  OutputFraae; 

IF  (OutputFrameA. Message  - DlUInput)  AND 

(OutputFrameA .DIUCommand .Activity  - Output)  THEN 

AFTER  NextMessageBitTime  DIUWritten  <-  TRUE; 

ELSE 


(*  Schedule  Transaction  timeout.  *) 

ResponseBitTime  :»  ComputeResponseBitTime (TransactionExecuting, 

(ChainA . Chainldentif ier  MOD  4)); 

AFTER  (TimeOut Value  + TransactionOutputTime)  TransactionTimeOut  <-  TRUE; 
TransactionTimeOutNotica  :*  CurrentNotice; 


END; 


END; 

END  ProcessTransaction; 

(***************** **************************  * ********* ************* ********j 

BEGIN 

NetworkPort  GetOutPort (RootNodelD) ; 

IOServicePort  GetOutPort (IOServicelD) ; 

LOOP 


WAITUNTIL  (ChainToProcess,  ProbeReset,  Reset) 


{*************  *******************  ***********  * *****) 
( * This  event  handles  the  Chain  Loading  mechanism  from 

the  I/O  Request  Processing.  First  it  sets  Chain  Finished 
to  FALSE  and  the  pointer  to  the  first  input  frame  to  nil, 
then  it  accumalates  some  time 

to  represent  the  loading  of  the  chain  into  the  IOS, 
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schedules  the  chain  timeout  event,  initailzes  the 
Network  Chain  Data  so  that  the  Input  Frames  can  ba 
procasaad  as  thay  ara  received,  sands  tha  first 
transaction  to  tha  network,  and  schedules  tha 
transaction  timeout  for  tha  first  transaction.  *) 
ChainToProcass : 


IF  Nat work ID  - 1 THEN 

SAMPLE  1.0  WITH  SystaoiProbo  [ProbeNumber  ] ; 

END  # 


(*  Craata  mamory  for  local  copy  of  tha  raaponsas 
for  this  chain.  *) 

NEW  (RasponsaCham) ; 

RasponaaChainA .AllF ailed  ;•  TRUE; 

RasponsaChainA . AnyFailad  FALSE; 

ResponseChainA . InputFramaQueue  InitQ {"InputFrameQueue",  FALSE, 


0); 


{*  Make  tha  response  available  to  the  I/O  System  Service. 

This  makes  the  chain  response  data  immediately  available 
by  keeping  the  data  on  tha  port. 

This  will  allow  the  I/O  System  Service  to  start  reading 
tha  IOS  whan  a chain  has  timed  out.  *) 

NOW  outport  [IOServicaPort] A . IOChainRasponsa  <-  ResponseChain; 


ChainUndarExecution  Act ivePortA. ChainToProcass; 


(*  Record  start  I/O  activity  data  collection  event. 

Increment  tha  proper  frame  counter.  *) 
StartlODataElament . Simulation Tima  clock; 


IF  ChainUn derExa cut ion A .Chain Identifier  < 20  THEN 


StartlODataElament .Frequency 
StartlODataElament . CyclicData . FramaCount 


Cyclic; 

ChainUndarExecution A .FramaCount 


CASE  chainUndar Execution A .Chainldent if ier  OF 


StartlODataElament. CyclicData. Covariation  StartNWlIOActivity; 

S tar t IODataElamant . Event ID  : “ 7 ; 

1 2: 

Start iODataElement .CyclicData . C_Variation  :*  StartNWlIOActivity, 
StartlODataElament. Event ID  8; 

I 3: 

Start IODataElement. CyclicData. C_Variation  StartNWlIOActivity; 

StartlODataElament. Event  ID  9; 

I 5: 

Start  IODataElamant.  CyclicData.  Covariation  StartNWIIActivity; 

Start  IODataElamant.  Event  ID  3.6; 

I 6: 

Start IODataElamant. CyclicData. Covariation  StartNWIIActivity; 

StartlODataElament. EventID  3.7; 


l 7: 

StartlODataElament .CyclicData. Covariation  :■  StartNWIIActivity, 

StartlODataElament  .EventID  3.8; 


I 9: 

StartlODataElament .CyclicData. Covariation  :*  StartNWlOActivity, 
Start IODataElamant. Event ID  22; 


| 10: 


Start IODataEleaent . CyclicData . Covariation  : - StartWWlOActivity; 
StartlODataElement .Event ID  :•  23; 

I 11: 

StartlODataElement .CyclicData. Covariation  StartNWIOActivity; 

Start IODataElement .Event ID  :«  24* 


END; 

ELS IF  (ChainUnderExecution A . Chainldantif ier  >-  300)  AND 
(ChainUnderExecutionA . Chainldantif iar  o 310)  THEN 

StartlODataElement .Frequency  NonCyclic; 

Start IODa taE lenten t .NonCyclicData.N_Variat ion  RaconfiglOActivity 

Start I ODataE lament .EvantID  30* 


END; 


IF  ({NetworkID  * 1)  AND 

(ChainUndarExacution A. Chainldantif iar  o 20))  OR 
((NetworkID  - 2)  AND 

( ChainUndarExacut ion A .Chainldantif iar  >»  300))  THEN 


Wr itaDataElamantTypa (Start IODataElement ) ; 


END; 


REPORT  "%d"  ChainUndarExacution A .Chainldantif iar 
TAGGED  "Chain  started  Execution . B; 

TransactionUndarExacution  Fir stQ (ChainUndarExacut ion A . 

Transact ionQueue) ; 

NumbarOfTransactions  QSiza (ChainUndarExacution A . 

TransactionQuaua) ; 

(*  Initialize  IOS  to  I/O  Request  processing  so  that 
I/O  Request  does  confuse  previous  chain  completion 
with  this  chain  completion  on  its  first  2ms  poll, 
it  this  chain  has  not  completed.  *) 

NOW  outport [ IOSarvicePort } A . ChainFinished  <-  FALSE; 

(*  Sand  out  the  first  transaction,  *) 

ProcassTransaction (FALSE,  NIL, ChainUndarExacution, 

TransactionUndarExacution,  NumbarOfTransactions, 
BitTimeForResponse) ; 


LOOP 


WAITUNTIL  (InputTransaction,  Tr ansae ti on TimeOut, 

StopChain,  DIUWritten,  Reset,  EndlOActivity,  ProbaRaset) 

(********************* ***********************★*************) 
(*  71113  ®vant  handles  the  Input  Frames  from  the  I/O  Network. 
It  places  the  Input  Data  in  the  Input  Frame,  cancels  the 
the  transaction  timeout  for  this  transaction,  checks  for 
more  frames  to  be  processed  for  this  chain,  if  so  the 
next  transaction  is  sent  to  the  network  and  the  and  the 
transaction  timeout  is  scheduled  for  the  next  transaction. 
If  no  more  transaction  are  to  be  processed  for  this  chain, 
the  Chain  Timeout  event  is  canceled  for  this  chain, 
and  then  Chain  Finished  is  set  and  the  Network  Chain  Data 
is  sent  to  I/O  Request  Processing.  *) 

InputTransaction : 

ResponseChainA  . AllFailed  ;«  FALSER- 

NEW  (Network  Input)  ; 

(*  Put  Network  Data  in  Input  Frame.  *) 
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WITH  Natworklnput*  DO 


TranaactionUndarExacution* . 

Identifier; 

TransactionUndarExacution  . 

OutputFrama  A . Address ; 
Transactionli^tlndicato^ 

InputFrama 


Transaction Identifier 
MaasagaAddrasa 


END; 

REPORT  "%d"  Natworklnput* .Tranaactionldantifiar 
TAGGED  "Transaction  complatad  normally."; 

INSERT  Networklnput  LAST  IN  ResponseChain* InputFrameQueue  ; 

QInsert  (Networklnput,  ResponseChain* . InputFrameCNeue,  FALSE) 

(*  Cancel  Transaction  Timeout  for  the  just  completed 
transaction.  *} 

CANCEL  TranaactionTimaOutNotica; 

(*  Check  for  more  transactions  to  process.  *) 

IF  NumbarOfTranaactiona  - 0 THEN 

Chains tatu a : - CompletedNormally; 

(*  Set  completion  flag  of  the  I/O  System 
service « « 

AFTER  BitTimeFor Response  + TranaactionTurnAroundTima 
EndlQActivity  <-  TRUE; 


ELSE 

ProcessTransaction (TRUE  f Networklnput, 
ChainUndarExacution, 

TransactionUnderExecution , NumberOf Transact ions , 
BitTiaeForResponse) ; 


END; 

(*  This  avant  will  handle  tha  transaction  timeout  event . 

It  assigns  transaction  timeout  in  tha  Network  Chain 
data  corresponding  to  this  transaction.  A chac  wi 
than  be  made  for  more  transactions  to  be  processed  for 
this  chain,  if  so  tha  transaction  timeout  is  scheduled 
for  tha  next  transaction.  If  no  more  transactions  are  to 
be  processed  for  this  chain,  the  Chain  Timeout  event  is 
canceled  for  this  chain,  and  then  Chain  Finished  is  set  and 
^ Nework  Chain  Data  is  sent  to  tha  I/O  Request  Processing. 

i TranaactionTimeOut: 


*) 


BitTimaForRasponaa  :■  °-0' 

ResponseChainA .AnyFailed  TROE; 

NEN (Networklnput) ; 

(*  Put  data  in  Input  Frame  for  this  transaction  indicating 
that  tha  currant  transaction  timad  out.  ) 

WITH  Natwork Input*  DO 

Tranaactionldantifiar  TransactionUndarExacution*. 

Idantifiar; 

Mas  sagaAddraa  a TransactionUndarExacution  . 

OutputFrama* . Add rasa ; 

TransactionTimaOutlndicator  TimadOut; 


END; 

REPORT  "%d"  Natworklnput* .Tranaactionldantifiar 

TAGGED  "Transaction  timad  out."; 
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(*  Put  Input  Frame  on  response  queue.  *) 

IKSERT  Network  Input  LAST  IN  ResponseChainA.  InputFrameQueue; 

Q Insert  (Networklnput,  ResponseChain* . InputFrameQueue,  FALSE) 

(*  Check  for  more  transactions  to  process.  *) 

IF  NumberOf Transact ions  - 0 THEN 

(*  Set  completion  flag  of  the  I/O  System 
service..  *} 

ChainStatus  CompletedNoraally; 

AFTER  BitTimeForResponse  + TransactionTurnAroundTime 
EndlOActivity  <-  TRUE; 


ELSE 


ProcessTransaction (TRUE,  Networklnput, 
ChainUnderExecution, 

TransactionUnderExecution,  NumberOfTransactions , 
BitTimeForResponse); 


END; 

{**************************tt*tttttt*tto#tttttt^#^^ 

(#  This  event  handies  a stop  chain  from  the  I/O  System 

Service  when  a chain  has  timed  out.  This  process 
marks  the  current  transaction  as  timed  out  and 
prepares  to  receive  the  next  chain.  M 
I StopChain: 

NEW (Networklnput)  ; 

(*  Put  data  in  Input  Frame  for  this  transaction  indicating 
that  tha  current  transaction  timed  out.  *) 

WITH  NetworkInputA  DO 

Transactionldentifier  TransactionUnderExecutionA . 
Identifier; 

Message  Address  : - Transact  ionUnder£xecutionA . 

OutputFrame  A . Address ; 

TransactionTimeOut Indicator  :»  TimedOut; 


END; 

{*  Put  Input  Frame  on  response  queue.  *) 

INSERT  Networklnput  LAST  IN  ResponseChain*.  InputFrameQueue; 
QInsert (Networklnput,  ResponseChainA . InputFrameQueue,  FALSE) ; 
ChainStatus  :»  timedout; 

EXIT; 

I EndlOActivity: 

IF  NetworkID  - 1 THEN 

SAMPLE  0.0  WITH  SystemProbe [ProbeNumber] ; 

END; 


NOW  outport [ IOServicePort ] A . ChainFinished  <-  TRUE; 

REPORT  "%d, " ChainUnderExecution* . Chainldentifier 
TAGGED  "End  I/O  Activity.”; 

{*  Record  end  I/O  activity  data  collection  event.  *) 
End I ODataE lament . SimulationTime  clock; 

IF  ChainUnderExecution A . Chainldentifier  < 20  THEN 


End I ODataE lament .Frequency 


:■  Cyclic; 


ChainUndarExecutionA .FrameCount; 


End  IODataElemant  .CyclicData.FraaaCount 
CASE  ChainUndarExacutionA Chainldantif iar  OF 


Is 


EndlODataElamant .CyclicData.  Covariation  :•  EndNWl IOActivity; 
EndlODataElamant  .EvantID  10  ' 

EndlODataElamant . CyclicData . IOChainStatua  : * ChainStatus ; 


I 2: 


EndlODataElamant . CyclicData . Covariation  : * EndNWl IOActivity ; 
EndlODataElamant . EvantID  11 * 

EndlODataElamant . CyclicData . IOChainStatua  : • ChainStatua ; 


I 3: 


EndlODataEl ament . CyclicData . C_Variation  : - EndNWl IOActivity; 

EndlODataElamant .EvantID  3.2; 

EndlODataElamant . CyclicData . IOChainStatua  ChainStatua; 


I 5: 


EndlODataElamant. CyclicData. C_Variation  :■  EndNWl  IActivity; 
EndlODataElamant  .EvantID  3.9; 

EndlODataElamant . CyclicData . IChainStatua  : ■ ChainStatua ; 


EndlODataElamant . CyclicData . Covariation  : - EndNWl IActivity ; 

EndlODataElamant  .EvantID  20 ' 

EndlODataElamant .CyclicData . IChainStatua  : - ChainStatua ; 


EndlODataElamant .CyclicData. Covariation  :*  EndNWl IActivity; 

EndlODataElamant.  Event  ID  21' 

EndlODataElamant .CyclicData. IChainStatua  :«  ChainStatus; 


I 9: 


EndlODataElamant  .CyclicData . Covariation 

EndlODataElamant .EvantID 
| 10: 

EndlODataElamant  .CyclicData . Covariation 
EndlODataElamant  .EvantID 

I Us 

EndlODataElamant . CyclicData . Covariation 
EndlODataElamant  .EvantID 


EndNWl OActivity ; 
25; 


EndNWl  OActivity  ; 
26; 


EndNWl OActivity ; 
27; 


END; 


ELSIF  (ChainUndarExacutionA . Chain Idantifiar  >•  300)  AND 
(ChainUndarExacutionA  Chainldantif  iar  <-  310)  THEN 


EndlODataElamant . Frequency  : * 
EndlODataElamant .NonCyclicData .N_Variation 
EndlODataElamant .EvantID  : * 


NonCyclic; 

Ra con figl OActivity ; 

31; 


END; 


IF  ((NatworkID  - 1)  AND 

(ChainUnderExecution A . Chainldantif iar  <- 


20))  OR 


( (NatworkID  - 2)  AND 

(ChainUnderExecution  AChainldentif  iar  >-  300)) 


THEN 
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WriteDataElementType  (EndlODataElement) ; 


END; 


EXIT; 

I DlUWritten: 

REPORT  "%d"  Transact ionUnderExecutionA , Identifier 

TAGGED  "DID  Output  Transaction  completed  normally."; 

(*  Chack  for  more  transactions  to  process.  *) 

IF  NuaberOfTransactions  - 0 THEN 

REPORT  "%d"  ChainUnderExecutionA .Chain Identifier 
TAGGED  "Output  Chain  has  completed  execution."; 

ChainStatus  CompletedNormally; 

IF  Network ID  - 1 THEN 

SAMPLE  0.0  WITH  SystemProbe [ProbeNumberl ; 

END; 

(*  Set  coapletion  flag  of  the  I/O  System  service..  *) 
AFTER  TransactionTurnAroundTime  EndlOActivity  <-  TRUE; 

ELSE 


TransactionUndarExecution  QSucc(TransactionUnderExecution, 

ChainUnderExecution A . Transact ionQueue ) ; 

DEC (Number Of Transact ions) ; 

WITH  Trans act ionDnderExecut ion A DO 

(*  Bit  Time  to  transmit  the  next  message.  *) 

Temp  Time  ApplicationTransmitBita  (ChainUnder  Execution1"  .Chain  Identifier, 
(Identifier  MOD  Max_Transactiona InChain) ] ; 

REPORT  "%d"  Identifier  TAGGED  "Transaction  started  Execution."; 

AFTER  TampTime  outport [NetworkPort] A .Output Transaction  <-  OutputFrame; 
AFTER  TempTime  DIUWritten  <-  TRUE; 

END; 


END; 


I Reset : 

EXIT; 

I ProbeReset: 

IF  NetworkID  - 1 THEN 

ClearProbe (SystemProbe[ProbeNumber] ) ; 
SAMPLE  1.0  WITH  SystemProbe [ProbeNumberl ; 
END; 


END; 


END; 

I ProbeReset : 

IF  NetworkID  - 1 THEN 

ClearProbe (SystemProbe (ProbeNumber ] ) ; 
SAMPLE  0.0  WITH  SystemProbe [ProbeNumberl ; 
END; 


| Reset : 


END; 

END ; 

END  10 S. 
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PROCESSOR 


DEFINITION  DEVM  Processor; 


(*  1/27/88  PRB  added  import  of  LONGREAL  *) 

FROM  Util  IMPORT  LONGREAL; 

EXPORT  ProcetsingUnit*; 

{* 

* a processing  unit  it  an  entity  that  contains  information  about  processes 

* which  compete  for  the  Processor. 

*> 

TYPE 

ProcessingUnit  - ENTITY 

Priority  ; INTEGER; 

Process ingRequired  : REAL; 

Process  ID  : ARRAY  (0  ..  31]  OF  CHAR; 

Frame  : INTEGER; 

WriteData  i BOOLEAN; 

ProcssngAfterBlock  : REAL; 

Data  : ADDRESS ; 

Process ingLeftToDo  : REAL;  (*  don't  touch  *) 

(*  1/27/88  PRB  changed  Started  to  type  LONGREAL  from  REAL  *) 

Started  : LONGREAL; (*  don't  touch  *) 

SendBackOutThisPort:  INTEGER;  (*  don't  touch  *) 
DataNritten  : BOOLEAN;  (*  don't  touch  *) 

END; 


END  Processor. 


PROCESSOR 


DEVM  Processor; 


(*  1/27/88  PRB  imported  DFLoatRaal  *) 

FROM  Conversions  IMPORT  DFloatToRaal; 

FROM  Controls  REACH  SystamProbe,  NumberOfP  robes;  {*  NOTICE  that  this  is  a REACH  and  not  and  IMPORT  ' this  *) 

(*  forcas  tha  danat  compiler  to  raad  controls .ddef  *) 

FROM  Sanddata  IMPORT  WriteDataElamentType,  CyclicDataType,  DataElamentType, 

CyclicVariationTypa,  FraquancyTypa; 


INPUTS 


SubaitProcess  : ProcessingUnit;  (*  submit  a procass  to  tha  procassor  *) 

StartSystam  : BOOLEAN;  (*  start  tha  system  procass  running  *) 

Reset  : BOOLEAN; 

ProbaRasat  : BOOLEAN ; 


PARA 

SystamPriority  : 

SystaoProcessingNaeded  : 

Sy 3 tamFraquan cy 

ContaxtSwitchTima 
P r o cas s orRaportL ava 1 
ProbaNumbar 


INTEGER;  {*  priority  of  system  procass  *) 
REAL;  (*  amount  of  processing  naadad  to 

* execute  the  system  procass  *) 

REAL;  (*  how  often  tha  system  needs 

* to  run  *) 

REAL;  (*  context  switching  time  *) 

INTEGER;  (*  report  parameter  *) 

INTEGER;  (*  which  system  probe  to  use  *) 


END; 


OUTPUTS 

VAR 

Completed 


Procass ingUnit;  (*  When  a procass  has  completed,  it 

* is  returned  to  the  caller  *) 


OH); 

EVENT  , J .. 

Proces sComplated  : BOOLEAN;  (*  check  for  completed  processes  *) 

RunSystam  : BOOLEAN;  (*  system  needs  to  run  *) 

TTPE 

Proces singQueue  - QUEUE  OF  DESCENDING  ProcessingUnit; 

CONST 

ContextSwitchPriority  - 12345678;  (*  big  number  *) 

VAR 

ReadyQueue  ; Process ingQueue;  (*  processes  waiting  for  processing  *) 

CurrentProcess  : Procass ingUnit;  {*  procass  that  comas  in  on  a port  *) 

ExecutingProcess  : Process ingUnit;  (*  process  that  has  the  processor  *) 

SystemProcass  : ProcessingUnit;  (*  the  system  procass  *) 

ContextSwitchProcess  : ProcessingUnit;  (*  process  which  represents  the  context  switch  time  *) 
Comp let ionNot ice  : EventPo inter; 

Proces sSwitchingTo  : ProcessingUnit;  (*  process  that  the  cpu  is  switching  to  *) 
OutputDataElament  : DataElamentType; 


PROCEDURE  BeginExecutionOf Process (DesiredProcess  : ProcessingUnit); 
BEGIN 

ExecutingProcess  DesiredProcess; 
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(*  1/27/08  PRB  changed  clock  to  longclock  *) 

ExecutingProcessA Started  Longclock; 

AFTER  ExecutingProceas A .Process ingLeftToDo  ProcessCompleted  <-  TRUE; 
CompletionNotice  Cur ran tNo ties; 

REPORT [ProcessorReportLevel]  "%s"  ExecutingProceas A .ProcaasID  TAGGED  "Started”' 
END  BeginExacutionOfProcess; 


BEGIN 

NEW  (SyatemProceas)  ; 

WITH  SystemProcassA  DO 

Priority  SyateaPriority; 

Process ingLeftToDo  SystemProceasingNeedad; 

ProcaasID  'System'; 

DataWrittan  :«■  TRUE; 

END; 

NEW (ContextSwitchProcess) ; 

WITH  ContextSwitchProcassA  DO 

Priority  :«  ContaxtSwitchPriority; 
ProceasingLeftToDo  Con text Switch Tima; 

ProcaasID  :«  'Context  Switch'; 

DataWrittan  TRUE; 

END; 


ExacutingProcaaa  :«  NIL; 
LOOP 


WAITUNTIL  EVENT 


SubmitProcass  : (*  process  is  ready  to  use  the  processor  *) 


CurrentProceas  ActivaPortA . SubmitProcass; 

<* 

* Figure  out  who  sent  the  process  to  you,  so  that  you  can 

* Mnd  it  back  to  them  once  the  process  has  completed. 

CurrentProcesa A . SendBackOutThisPort  GetOutPort (GatlnNoda { 

ActivePort A . index) } ; 

CurrentProcessA .Process ingLeftToDo  :«  CurrentProcaaaA.ProcaasingRequired; 
CurrentProceas A. DataWrittan  NOT  CurrentProceas A .WritaData; 


REPORT ( ProcessorReportLevel ] "%s"  CurrentProceas A .ProcaasID  TAGGED  "Submitted"; 

IF  ExecutingProceas  - NIL  THEN 

INSERT  CurrentProceas  IN  ReadyQueue; 

BeginExacutionOfProcess (ContextSwitchProcess) ; 

ProcessSwitchingTo  CurrentProceas; 

SAMPLE  1.0  WITH  SystemProbe (ProbaNumber ] ; 

ELSIF  CurrentProceas A .Priority  > ExecutingProceas A .Priority  THEN 
CANCEL  Coop let ionNot ice; 

(*  1/27/88  PRB  Changed  calculation  to  double  precision  *) 

ExecutingProcessA .ProcessingLeftToDo  :«  ExecutingProceas A .Process ingLeftToDo  - 

DF loatToRaal (LongClock  - ExecutingProceas  A . Started) ; 

REPORT [ProcessorReportLevel]  "%a,%10.6f"  ExecutingProcessA .Process ID, 
ExecutingProceasA. Process ingLeftToDo  TAGGED  "Preempted"; 

INSERT  ExecutingProceas  IN  ReadyQueue; 

INSERT  CurrentProceas  IN  ReadyQueue; 

BeginExacutionOfProcess (ContextSwitchProcess) ; 

ProcessSwitchingTo  :«  CurrentProcesa; 

ELSIF  ExecutingProcessA .Priority  - ContaxtSwitchPriority  THEN 
INSERT  CurrentProcesa  IN  ReadyQueue; 

(*  1/27/88  PRB  Changed  calculation  to  double  precision  *) 

IF  ExecutingProceas A .Started  - LongClock  THEN 
ProcessSwitchingTo  FirstQ (ReadyQueue) ; 

END; 

ELSE 

INSERT  CurrentProceas  IN  ReadyQueue; 

END; 
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j ProcesaCcmpleted  : (*  check  for  completed  processes  *) 

REPORT ( Process orReportLevel]  "%s"  ExacutingProcess A .Process  ID  TAGGED  "Finished"; 

IF  NOT  { (Execut ingProcassA. Prior ity  - SystemPriority)  OR 

(ExecutingPr ocas a A. Priority  - ContaxtSwitchPriority) ) THEN 
NOW  outport  [ExecutingProceasA  .SendBackOutThiaPort] A .Completed  <•  ExacutingProcess; 
END; 

IF  ExecutingProcessA  Priority  o ContaxtSwitchPriority  THEN 
BaginExecutionOfProcess  ( Con textSwitchPro cess) ; 

IF  QSize (ReadyQuaua)  O 0 THEN 

ProcaaaSwitchingTo  FiratQ (ReadyQuaua) ; 

ELSE 

ProcaaaSwitchingTo  NIL; 

END ; 

ELSIF  QSize (ReadyQuaua)  o 0 THEN 

IF  ProcaaaSwitchingTo  - FiratQ (ReadyQuaua)  THEN 
REMOVE  FIRST  CurrentProcesa  FROM  ReadyQuaua; 

IF  (MyNodelD  - 45)  AND  (NOT  Curran tPr oca as A .DataWrittan)  THEN 
Curran tProcessA. DataWrittan  : - TRUE; 

OutputDataElamant. SimulationTime  clock; 

OutputDataElamant. Frequency  Cyclic; 

OutputDataElament . CyclicData . FrameCount  CurrantProcaaaA. Frame; 

OutputDataElement. CyclicData. C_Variat ion  :■  StartConputing; 

OutputDataElamant. CyclicData. ProcaaaingNaadadThiaFrama 

CurrantProcaaaA . ProcaaaingRaquirad  + Current? rocaaaA .ProcaangAftarBlock; 
CASE  CurrantProcaaaA. Priority  OF 

10;  OutputDataElamant.  Event  ID  1; 

| 9;  OutputDataElamant. Event ID  2; 

j 8:  OutputDataElamant. Event ID  3; 

END; 

WriteDatAElamantType  (OutputDataElamant)  ; 

ELSIF  (MyNodelD  - 46)  AND  (NOT  CurrantProcaaaA .DataWrittan)  THEN 
CurrentProcassADataWritten  TRUE; 

OutputDataElamant. SimulationTime  clock; 

OutputDataElamant. Frequency  :«  Cyclic; 

OutputDataElamant. CyclicData. FrameCount  CurrentProcesa A Frame; 

OutputDataElamant. Cyc 1 ' cData. Covariation  StartChain; 

CASE  CurrantProcaaaA  Priority  OF 

10:  OutputDataElamant. Event ID  13; 

| 9:  OutputDataElamant.  Event  ID  :*  14; 

| 8:  OutputDataElamant. Event ID  15; 

END; 

WritaDataElamantTypa  (OutputDataElamant) ; 

END; 

BaginExecutionOfProcess (CurrentProcaaa) ; 

ELSE  (*  procesa  of  higher  priority  arrived  during  context  switch  *) 
BaginExacutionOfProcaaa (ContaxtSwitchProcaaa) ; 

ProcaaaSwitchingTo  FiratQ {ReadyQuaua ) ; 

END; 

ELSE 

ExacutingProcaaa  NIL; 

SAMPLE  0.0  WITH  SyatamProba [ProbaNumbar] ; 

END; 

| RunSyatam  : {*  system  process  needs  to  run  *) 


INSERT  SyatamProcaas  IN  ReadyQuaua;  . 

REPORT [ProcesaorRaportLaval]  "%s"  SyatamProcaas A .Process ID  TAGGED  Submitted  , 

IF  (ExacutingProcess  o NIL)  AND  ( (ExecutingProcessA  .Priority  - ContaxtSwitchPriority)  AND 

(QSize (ReadyQuaua)  - 1))  THEN 


(*  Trying  to  submit  th.  procass  during  a context  switch  to  th«  background  procsss.  This  rsquirss 
* a second  context  switch  to  occur  before  the  system  process  can  run. 


ProcessSwitchingTo  NIL;  (*  has  affect  of  causing  another  context  switch  *) 
ELSIF  ExacutingProcess  - NIL  THEN 

BeginExecutionOfProcass (ContaxtSwitchProcaaa) ; 

ProcessSwitchingTo  SystamProcass; 

SAMPLE  1.0  WITH  SyatamProba (ProbaNumbar ] ; 

ELSIF  ExecutingProcessA. Priority  o ContextSwitchPriority  THEN 
CANCEL  Comp let ionNot ice; 
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(*  1/27/88  PRB  Changed  calculation  to  doubla  praciaion  *) 

ExacutingProcaaa* .ProcasaingLaftToDo  ExacutingProcaaaA.ProcaaaingLaftToDo  - 

DFloatToRaal (LongClock  - ExacutingProcaaa* .Startad) ; 

INSERT  ExacutingProcaaa  IN  RaadyQuaua; 

REPORT [Procaa a orRaportLaval]  "%aH  ExacutingProcaaaA.ProcaaaID  TAGGED  "Praamptad"; 
BaginExacutionOfProcaaa (ContaxtSwitchProcaas) ; 

Procaa a SwitchingTo  : - SyatamProcaaa; 

END; 

AFTER  SystaaFraquancy  RunSyatam  <-  TRUE; 

I StartSyatam  : (*  Start  tha  systam  procaa a running  pariodically  *) 

NON  RunSystam  <-  TRUE; 

| Raaat  : 

IF  (ExacutingProcaaa  o NIL)  AND  ( (ExacutingProcaaa A .Priority  <>  SyatamPriority)  AND 

(ExacutingProcaaaA. Priority  o ContaxtSwitchPriority) ) THEN 

DISPOSE (ExacutingProcaaa) ; 

END; 


(* 

* Claar  tha  queue 
*> 

FOREACH  ExacutingProcaaa  IN  RaadyQuaua  DO 

REMOVE  FIRST  ExacutingProcaaa  FROM  RaadyQuaua; 

IF  (ExacutingProcaaa A. Priority  o SyatamPriority)  AND 

(ExacutingProcaaa A. Priority  o ContaxtSwitchPriority)  THEN 
■ DISPOSE (ExecutingProcess) ; 

END; 

END; 


ExacutingProcaaa  NIL; 

| ProbaRasat  : 

ClaarProba (SyatamProba [ProbaNumbar] ) ; 

IF  ExacutingProcaaa  O NIL  THEN 

SAMPLE  1.0  WITH  SyatamProba  {ProbaNumbar] ; 
ELSE 

SAMPLE  0.0  WITH  SyatamProba [ProbaNumbar] ; 
END; 


END; 

END; 

END  Procaaaor. 
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MATH 
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DEFINITION  MODULE  Math; 


EXPORT  QUALIFIED  RaalMod; 

PROCEDURE  RaalModfX  : REAL; 

Y : REAL)  : REAL 

END  Math. 
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MATH 
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IMPLEMENTATION  MODULE  Math; 

FROM  Math  Lib  0 IMPORT  mod; 

PROCEDURE  RaalMod(X  : REAL; 

Y : REAL)  : REAL; 

BEGIN 

RETURN  (mod(X,  Y) ) ; 

END  RaalMod; 

END  Math. 
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IOSERVICE 


DEFINITION  DKVM  IOSarvica; 


FRC3M  IOS  REACH  ChainTypa* , ChainStatuaData*; 

FROM  TypaConat  IMPORT  NumbarOfNatworka  ; 

EXPORT  IORaquaatTypa* , IORasponsaTypa*, 

IQActivityTypa , RaquastActivityTypa,  RasponsaActivityTypa, 
NatvorkManagarActivityTypa, 

Natwor kManagarSa rvi caRaqua  at* , NatworkHaalthTypa, 

Chain Statu a Typa,  NawNatworkStataTypa  * , 

ChainExacu tadW it hou t£r ror , RalaaaaChalnRaapon  saMamory; 

TYPE  NatworkHaalthTypa  - (InSarvica,  OutOfSarvica)  ; 

IOActivityTypa  - (ApplicationRaquaat,  NatworkManagarRaquast, 
MonitorForFault,  ApplicationRasponsa, 

NatworkManagarRasponsa,  FaultMonitorRaaponaa) ; 

RaquastActivityTypa  - [ApplicationRaquaat  ..  MonitorFor Fault] ; 

RaaponaaActivityTypa  - [ApplicationRaaponaa  ..  FaultMonitorRaaponaa]; 

NatworkMAnagarActivityTypa  - (GrowNatwork,  RapairFault,  SwitchRootLink); 

Chain Statu a Typa  - (NoFaulta,  CoomunicationFault, 

NotExacutad) ; 


NawNatworkStataTypa  - ENTITY 

NatWorkID  : INTEGER; 

Stata  : NatworkHaalthTypa; 

MonitorChain  : ChainTypa; 

END; 

IORaquaatTypa  • ENTITY 

Priority  : INTEGER; 

Idantifiar  : INTEGER; 

RaquaatTimaoutValua  : REAL; 

OnDaoand  : BOOLEAN; 

Frana  : INTEGER; 

RaaponaaExpactad  : BOOLEAN; 

CASE  RaquastTypa  : RaquastActivityTypa  OF 

ApplicationRaquaat : 

ChainArray  : ARRAY  [1  ..  NumberOfNetworks  ] OF  ChainTypa; 
| NatworkManagarRaquast,  MonitorForFault : 

Chain  ; ChainTypa; 


END; 


END; 


IORaaponaaTypa  - ENTITY 

Idantifiar  : INTEGER; 

CASE  RaaponsaTypa  : RaaponaaActivityTypa  OF 
ApplicationRasponsa : 

Frama  : INTEGER; 

ChainStatus  : ARRAY  (1  ..  NumbarOfNetworks]  OF  ChainStatusTypa; 

RaaponaaArray  : ARRAY  [1  ..  NumberOfNatworks]  OF  ChainStatuaData; 

I NatworkManagar Response,  FaultMonitorRaaponaa: 

Rasponaa  : ChainStatuaData; 

END; 
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ENTITY 


NatvorkManagarSarvicaRaquast  - 

CASE  SarvicaRaquaat  : NatvorkManagarActivityTypa  OF 
GrowNstwork: 

ActivsRootLink  : IFTEGER; 

| RapairFault; 

MonitorChainRasponas  : IOR* spoils ®Typ«; 

| SwitchRootLink : 

FailodRootNods  : INTEGER; 

NawRootNods  : INTEGER; 


END; 


END; 

'„*.**..«*«* — — ******  ***> 

PROCEDURE  ChainExacutadWithoutError (Chain  : ChainStatuaData)  : BOOLEAN; 

(*,.t.******^— ""””******* 

PROCEDURE  RalaasaChalnRaaponsaMamory (VAR  Raapons.  : ChainStatuaData) ; 

,.*.*******************”***‘******************’‘***) 


************************* 


END  IOSarvica. 


IOSERVICE 


(****.«******************************‘************t*******t********************, 
(*  1/27/88  This  change  supports  implements : 

a)  Waiting  until  all  higher  priority  processing  is  completed 
before  submitting  a pending  I/O  Request. 

b)  When  a pending  I/O  request  is  made,  the  semaphore  is 

marked  busy  when  the  pending  I/O  processor  request  is  made.  *) 

(*.h*«*o******************“****“‘****“***‘***h‘**““**,*“',‘*““**m*> 
DEVM  IOService; 

FROM  10 S REACH  ChainType*,  ChainStatusData*, 

InputFraaeType*,  TransactionType*; 

FROM  Processor  REACH  ProcessingUnit*; 

FROM  Controls  REACH  SystamProba,  NumberOf Probes; 

FRCM  CantralDB  IMPORT  lOSConnectionType,  FindlOSConnections, 

ReadNodeln terConnections ; 

FROM  IOS  IMPORT  TimeOut IndicatorType; 

FRCM  GrowNet  IMPORT  MakaMoni  tor  Request; 

FRCM  Utilities  IMPORT  ManagerChainUnloadTime,  ComputeChainTimeout; 

FROM  TypeConst  IMPORT  StatusType,  NumberOfNetworka,  NumberOf IOSPerChannel, 
NodaAr  rayTypa ; 

FRCM  BusMassag  IMPORT  MesaageType,  IOActivityChoica; 

FRCM  Senddata  IMPORT  DataElementType,  FrequencyType,  NonCyclicVariationType, 
NonCyclicDataType,  WriteDataElementType; 

FRCM  Math  IMPORT  RealMod; 

IMPORT  SYSTEM; 

IMPORT  QuauaM; 

EXPOSE 

(ttt**it«*i**m**tit*t***Mtimit»i»*«*t*«*t**o«t****»*****it**) 

PROCEDURE  ChainExacutadWithoutError (Chain  : ChainStatusData)  : BOOLEAN ; 
BEGIN 

RETURN  NOT ( (Chain A .An yFailed)  OR  (ChainA . AllFailad)  OR 
(Chain A .ChainTimeOut Indicator  - TimedOut)); 

END  ChainExacutadWithoutError; 

(*************************************** ******************** ********** t) 

PROCEDURE  RalaasaChainRasponsaMamory  (VAR  Response  : ChainStatusData) , 

VAR  Frame  : InputFrameType; 

ElamantCounter  : INTEGER; 

NumberOf Elements  : INTEGER; 

BEGIN 

IF  Response  O NIL  THEN 

NumberOf  El  aments  QSize  (Raspon  saA . InputFrameQueue) ; 

FOR  ElementCounter  :■  1 TO  NumberOf Elements  DO 

Frame  : - QRemova  (Response A « InputFrameQueue,  TRUE) ; 


IF  Frame A .TransactionTimeOut Indicator  - NormalCoapletion  THEN 
DISPOSE  (Frame A . InputFrame) ; 

END; 

DISPOSE (Frame); 

END; 

dispose  (Response A . InputFrameQueue,  SIZE  (Frame) ) ; 

DISPOSE (Response) ; 

ELSE 


WriteLn (ParamOut ) ; 

WriteString (ParamOut,  "Tried  to  DISPOSE  a NIL  Chain  Response . " ) ; 
WriteLn (ParamOut ) ; 


END; 

END  ReleaseChainResponseMemory; 

(*** * ******************* ******* * *************************  ************** ) 


END; 


INPUTS 

EVENT  IOServiceRequest 

RtnNe two rkTo Service 
ProcessorResponse 
Mi s s edDeadLine 

Reset 

ProbeReset 

VAR  DataFromlOS 

Chain Completed 

PARA  Manager  IDNetwork2 
Application  ID 
IOP Identifier 
Controls I den tif ier 
StrategyForReconfiguration 
ChainProcessing 10 OH z 
Ch  ainP  r o ce  s s ing  5 OH  z 
ChainProcess ing2 5H z 
EndOfChainProcessinglOOHz 
En  dOf  Cha  inP  roce  s s i ng5  0 H z 
EndOf ChainProcess ing2 5Hz 
EndOf Ch a inP r oce s s i ngMon i t or 
Probe Number 


IORequestType; 
NewNetworkStateType ; 

Process in gUnit; 

INTEGER; 

BOOLEAN; 

BOOLEAN; 

ChainStatusData; 

BOOLEAN; 

INTEGER; 

ARRAY  [1  ..  3]  OF  INTEGER; 
INTEGER; 

INTEGER; 

INTEGER; 

REAL; 

REAL; 

REAL; 

REAL; 

REAL; 

REAL; 

REAL; 

INTEGER; 


END; 

OUTPUTS 

VAR  Chain To IOS 

ApplicationResponse 
IOManager2Response 
Manage r S ervi ceRqs t 
Proces  sorRequest 
Se  rvi  c eA  vai  1 ab  1 e 
Stop I OS 

END; 

TYPE  IOServiceStateType  * RECORD 


: ChainType ; 

: IOResponseType; 

: ChainStatusData; 

: NetworkManagerServiceRequest; 
: ProcessingUnit; 

: BOOLEAN; 

: BOOLEAN; 
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ExecutinglOOHz 
Executing 50Hz 
Executing25Hz 


BOOLEAN 

BOOLEAN 

BOOLEAN 


NatworkHaalth  : ARRAY  (1  ..  Nu*b«rOfN«twor ks  ] OF  N»tworkH«althTyp«; 
Activ»RootLink  : ARRAY [1  ..  Nuab«rOfNetworks ] OF  INTEGER; 

END; 

NatworkConnactionTypa  - RECORD 

NatworkConnactiona  : IOSConnactionTypa; 

ConnactionStatua  : ARRAY  (1  ..  Numbar Of IOSParChannal]  OF  StatusTypa 

END; 

IOSarvicaNetworkConnactionsTypa  - ARRAY  [1  ..  NumbarOfNatworka  J OF 
Natwor  kCon  nac  t io  nTypa ; 

RaquastExacutionStatua  - ENTITY 

Raquaat  : IORequestTypa; 

CASE  RaquastTypa  : IOActivityTypa  OF 

ApplicationRaquaat: 

ExocutingOn  : ARRAY  (1  ..  NumbarOfNatworka]  OF  BOOLEAN; 
PortArray  : ARRAY  [1  . . NumbarOfNatworka]  OF  INTEGER; 

| NatworkManagarRoquaat  , MonitorForFault: 

Port  : INTEGER; 

END; 

END; 

SamaphoraTypa  - ENTITY 

Priority  INTEGER; 

ExacutionStatua  : RaquaatExacutionStatua; 

END; 

SomaphoroQuauaType  - QUEUE  OF  DESCENDING  SamaphoraTypa; 

Algor ithmTypa  - (PowarUp,  IORaquaatSchadula,  IORaaponaaSchadula, 

Ou tpu tRa spo n a aS chadula , StartPandinglO,  NatworkRapair , 

St artFau ItMonit  or ) ; 

UnloadRaquaatType  - RECORD 

Raaponaa  : IORaaponaeTypa; 

CASE  RaaponaaTypa  : IOActivityTypa  OF 

NetworkManagerReaponaa , FaultMonitorRaaponaa : 

Manager ID  : INTEGER; 

END; 

END; 

DataTypa  • RECORD 

CASE  Function  : AlgorithmTypa  OF 
PowarUp : 

| IORaquaatSchadula: 

IORaquast  : IORaquaatTypa; 


| IORaaponsaSchadula: 


IOResponse  : IOReaponaaType; 


I OutputRaaponseSchadula: 

Rat®  : INTEGER; 

| StartPendinglO: 

(*  1/27/88  *)  RaquastStatus  : RaquastExecutionStatus; 

| StartFaultMonitor : 

| NatworkRepair : 

RepalrData  : NatworkManagarSarviceRaqueat; 

END; 

END; 


DataPointar  - POINTER  TO  DataType; 


EVENT  IOCooplationPoll  : RaquastExecutionStatus; 

InitializaSarvica  : BOOLEAN ; 


CONST  IOSystamSarvicePriority 
NetworkID2 


1; 

2; 


Powerup I n t ia 1 i za 
RaquastPr ocas sing 
RasponaeCooipletionP  rocaa  sing 
Cha inP  rocaa a ingOvar haad 
EndOfChainProcassingOvarhead 
ChainP rocaa a ingl Transact ion 
ChainProc as a ing2 Transact ions 
EndOfChainProcaasinglTransaction 
EndOfChainProcaa  sing2Tranaact ion  s 
SwitchRootLinkProcessing 


0.000100; 

0.000025; 

0.000025; 

0.000050; 

0.000050; 

0.000018; 

0.000036; 

0.000052; 

0.000104; 

0.000025; 


SamaphoreGr anted  - >1; 
SamaphoreNot Gran ted  - -2; 
NoPandingRaquast  - -3; 


VAR  FaultMonitor2 
Sarvi caRoquea t 
RaquastToSarvi ca 
RaaponsaData 
NewNetworkStata 
IOSarvicaStata 
PandingRaquest 
PandingStatus 
IOSystamStatus 
Sarvi caNatworkRaquaat 
IONetworkConnections 
InterfacelD 

NatworkOu tO f Sarvi c ©Tima 
TimeNatworkOut Of Sarvi ca 
RaquaatTiaa 
OnDanandRaquas  tDalay 
T imeToUn loadRaquaa  t 
FailedRootN umber 
NetworkCounter 
Intar facaCountar 


IORaquaatType; 

IORequestType; 

RaquastExecutionStatus ; 

Un 1 oa dReque s t Type ; 

NewNetwor kStateType ; 
IOServiceStateType; 

Semaphore Type ; 

INTEGER; 

BOOLEAN; 

Na  twor  kttanager  Sarvi  caRequ  as  t ; 
IOServicoNatworkConnectionsType ; 
INTEGER; 

ARRAY  (1  ..  Numb erOfNe two rks]  OF  REAL 
REAL; 

REAL; 

REAL; 

REAL; 

INTEGER; 

INTEGER; 

INTEGER; 


Procassinglnformation 

Power UpProces sing 

NatworkData 

ProcaasRaquast 

PandinglOProcassing 

ResponaaDataProcossing 

RootLink Switchprocessing 


DataPointar; 
DataPointar; 
DataPointar; 
DataPointar; 
DataPointar; 
DataPointar; 
DataPo inter; 
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Rapai  rNe  two  rkP  roc®  a s ing 
PoverUpRequest 
ProceasReaponse 
P rocaa a ingOutputRasponse 
Proces flingS tar tPendinglO 
P r ocas  s ingNetworkRepair 


DataPo intar; 
Procaa  singUnit ; 
Pro ce* singUnit; 
ProcaflflingUnit; 
Procaa flingOn it ; 
ProcaasingUnit; 


DataCollactionRacord  : DataElementType; 


NetworkManager  2Port 
ApplicationPort 
IOPPort 
ControlaPort 


INTEGER; 

ARRAY  (1  ..  3]  OF  INTEGER; 
INTEGER; 

INTEGER; 


Network2 Connections 

(**** t ****** ****** ******* ****** 


NodaArrayTypa; 

************************************ 


tide*****) 


MODULE  S anaphora; 

FROM  SYSTEM  IMPORT  ADDRESS; 


FROM  QuauaM  IMPORT  InitQ,  PrQInsert,  QSize,  QRamova,  FirstQ, 
QSucc,  carrier; 

IMPORT  SanaphoraTypa , Semaphore QuaueType,  SemaphoraGrantad, 
SaoaphoreNot Gran ted,  NoPandingRaquaflt; 

IMPORT  WriteString,  WriteLn,  ParanOut; 


IMPORT  dmeasure,  System? robe,  ProbeNumber; 

EXPORT  Request , Release,  NextRaquaat,  Sanaphoraldla, 


SatSamaphora I die ; 


VAR  Idle  : BOOLEAN; 

SemaphoraQueue  : SamaphoreQueuaType; 

(.t*tt.tt*.i*«««*««**'‘'«****‘*‘*'***'*'*“‘““'‘""*‘*““"**t'1 


PROCEDURE  R*qu«st (Samaphora  : S«o*phor*Typ«)  : INTEGER; 
VAR  Status  s INTEGER; 


BEGIN 

IF  Idle  THEN 

Status  :•  SemaphoraGrantad; 
Idle  FALSE; 


ELSE 


Status  SemaphoraNotGranted; 
INSERT  Semaphore  IN  SamaphoreQueue; 


END; 


RETURN (Status) ; 

END  Request; 

(*  This  function  returns  the  priority  of  the  highest  priority  P^ding 
request.  If  no  request  is  waiting  the  semaphore  is  sat  to  idle 
and  No  pending  request  is  returned.  *) 

PROCEDURE  Release  (VAR  Status  : INTEGER) ; 


VAR  PendingRequest 
BEGIN 


Semaphore  Type; 


Idle  : " TRUE; 

IF  QSize (SamaphoreQueue)  <>  0 THEN 


PendingRaquest  :«  FirstQ(SemaphoreQueue); 
Status  PendingRaquest*. Priority; 


ELSE 


Status  NoPendingRequest ; 


END; 


END  Ralaasa; 

(t***a*#tttt*****#***tt****a*********t**t*#ttM4t#tttt#t##tttttt#tM###^ 

PROCEDURE  NaxtRaquast (VAR  Raquast  : SemaphoraType) ; 

BEGIN 

IF  QSiza (SamaphoreQueue)  > 0 THEN 

REMOVE  FIRST  Raquast  FROM  SamaphoreQueue; 

Idle  FALSE; 

SAMPLE  1.0  WITH  SystamProba [ProbaNumber ] ; 


ELSE 


WriteString (ParamOut, 
WriteLn (ParamOut) ; 
WritaString (ParamOut, 
WriteLn (ParamOut ) ; 


"Problem  with  s amphora  logic."); 

"Trying  to  remove  SEMAPHORE  FROM  EMPTY  QUEUE.") 


END; 


END  NaxtRaquast; 


( ********** ******* ******************************** 
PROCEDURE  Semaphore Idle (VAR  Status  : BOOLEAN); 


**************** *****) 


BEGIN 


Status  : - Idle ; 

END  Semaphore  Idle; 

(**********  *********************t*A** 
PROCEDURE  SetSamaphoraldla ; 

BEGIN 


********************************** 


) 


Idle  TRUE; 

END  SetSamaphoraldla; 

(***t*************t********#****#tttttt#tt44ttott^tMM^^^^^^^^^^ 

BEGIN 


Idle  TRUE; 
END  Semaphore; 


PROCEDURE 


SubmitRequastProcessing (Request 

WritaTheData 

FrameCount 

Processing 

ProcessPriority 


DataPointer; 
BOOLEAN; 
INTEGER; 
REAL; 
INTEGER)  ; 


VAR  ProcessRequest  : ProcessingUnit; 


BEGIN 
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NEW  (Process  Request) ; 
WITH  ProcessRequestA  DO 


Priority  ProcessPriority; 

Process ingRequired  Processing; 

WriteData  : - WriteTheData; 

Frame  •“  FraineCount; 

ProcessID  s-  ' Requestprocessing' ; 

Data  •“  Request; 


END; 


NOW  outport ( IOPPort] A .ProcessorRequest  <-  ProcessRequest; 

END  SubmitRequestPro cessing; 

(**«******»*********«******************************************************) 

PROCEDURE  SubmitUnloadlORaqusst (SarvicaRaaponaa  : DataPointar; 

Processing  * REAL; 

ProcessPriority  : INTEGER); 

VAR  ProcessRequest  : ProcessingUnit; 

BEGIN 

NEW (ProcessRequest) ; 

WITH  ProcessRequest A DO 

Priority  :■  ProcessPriority; 

ProcessingRequired  Processing; 

WriteData  ’*  FALSE; 

ProcessID  :»  'UnloadlORequest' ; 

Data  :•  ServiceResponse; 


END; 

NOW  outport ( IOPPort ]A. ProcessorRequest  <-  ProcessRequest; 

END  SubmitUnloadlORequest; 

PROCEDURE  ResponseCompletion (Response  : IOResponseType) ; 

VAR  ChainCounter  : INTEGER; 

BEGIN 

WITH  ResponseA  DO 

IF  ResponseType  m ApplicationResponse  THEN 

FOR  ChainCounter  1 TO  NumberOfNetworks  DO 

IF  Chains tatus [ChainCounter]  o NotExecuted  THEN 

IF  (ResponseArray [ChainCounter] A . AnyFailed)  OR 

(ResponseArray  [ChainCounter ] A . AllFailed)  THEN 

ChainStatus [ChainCounter]  CoomunicationFault; 

ELSE 

ChainStatus [ChainCounter ] : - NoFaults ; 

END; 

ELSE 

{*  Chain  not  executed  so  nothing  to  process.  *) 


END; 


END; 


ELS IF  (ResponaeType  - NetworkManagerReaponse)  OR 
(ResponaeType  - FaultMonitorReaponse)  THEN 

(*  Network  Manager  is  responsible  for  processing 
these  I/O  responses.  *) 


END; 


END; 


END  ResponseCoopletion ; 

( ************** ****************************************** ******* ***********} 
{*  This  procedure  marks  a root  link  on  Network  2 failed.  *) 

PROCEDURE  FailRoot Link (VAR  RootLinkStatus  ; NetworkConnectionType; 

RootLink  : INTEGER)  : INTEGER; 

VAR  Root LinkCoun ter  : INTEGER; 

FailedNumber  : INTEGER; 


BEGIN 

FOR  Root  LinkCoun  ter  1 TO  Number  Of  IOSPerChannel  DO 

IF  RootLinkStatus  .NetworkConnections  {Root  LinkCoun  ter]  .GPCAddress 
- RootLink  THEN 

RootLinkStatus. ConnectionStatus [Root LinkCoun ter]  Failed; 

FailedNumber  RootlinkCounter; 


END; 


END; 


RETURN (FailedNumber) ; 

END  FailRootLink; 

{****************************** ************************** ******************) 

PROCEDURE  SwitchRoot Links (VAR  RootLinkStatus  : NetworkConnectionType; 

NetworkID  : INTEGER; 

FailedNumber  : INTEGER)  : INTEGER; 

VAR  RootlinkCounter  : INTEGER; 

NewRootLink  : INTEGER; 

BEGIN 

WITH  RootLinkStatus  DO 
Root LinkCoun ter  : » 1 ; 

LOOP 


IF  ConnectionStatus [RootlinkCounter]  - Idle  THEN 

(*  A new  root  link  has  been  found.  *} 

ConnectionStatus [RootlinkCounter]  Active; 

NewRootLink  :«  NetworkConnections [RootlinkCounter] .GPCAddress 

EXIT; 

ELS IF  RootlinkCounter  < NumberOf IOSPerChannel  THEN 
RootLinkCounter  :»  RootLinkCounter  + 1; 


B-60 


ELSE 


{*  A good  root  link  cannot  be  found.  *) 
NewRootLink  0; 

EXIT; 


END; 


END; 

END ; 

RETURN  (NewRootLink) ; 

END  SwitchRootLinks; 

******************************************************* ******************) 
PROCEDURE  Compute  I OLoadTime  ( IORequest  : IORequestType; 

ServiceState  : IOServiceStateType)  : REAL ; 


VAR  LoadTlme  : REAL; 

^ **************t** ****** ******************** ******************* ********) 

* This  function  looks  at  the  first  transaction  in  chain  1 of 

application  IORequest  to  determine  if  the  request  is  an  separated-! 
reqeust.  If  so,  TRUE  is  returned,  otherwise,  FALSE  is  returned.  ) 
PROCEDURE  SeparatedIRequeat  (Chain  : ChainType)  ; BOOLEAN; 

VAR  Transaction  : Trans actionType; 

BEGIN 

Transaction  FirstQ (Chain A .TransactionQueue) ; 

IF  (Transaction A . OutputFrameA .Message  - DlUInput)  AND 

(TransactionA  ,OutputFrameA  .DlUCommand.  Activity  - Input)  THEN 

RETURN  (TRUE)  ; 


ELSE 


RETURN (FALSE) ; 


END; 

END  SeparatedIRequest; 

(**********************************************************************> 

BEGIN 

IF  IORequest A .RequestType  - ApplicationRequest  THEN 

(*  Need  to  check  for  type  of  request,  Grouped,  Separated-I, 
Separated-0 . Separated  I has  different  loading  time.  *) 

IF  SeparatedIRequest ( IORequest A.ChainArray[l])  THEN 

LoadTlme  :-  2.0  * ChainProcessingOverhead; 


ELSE 

CASE  IORaquestA . Identifier  OF 
100: 

LoadTlme  (2.0  * ChainProcessingOverhead)  + ChainProcessinglOOHz; 
l 50: 

LoadTime  :«  (2.0  * ChainProcessingOverhead)  + ChainProcessingSOHz; 

I 25: 
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END; 


LoadTim®  (2.0  * ChainProcesaingOverhead)  + ChainProc®ssing25Hz; 


END; 


WITH  S®rvic®Stat®  DO 

IF  NOT  ( (N®tworkH®alth [ 1 ] m InService)  AND  (N®tworkH®alth  [2] 
- InS®rvic®) ) THEN 

(*  Cut  load  time  in  half  sine®  only  on®  network 
is  in  s®rvic®.  *) 

LoadTim®  0.5  * LoadTim®; 


END; 


END; 

ELSIF  IOR®questA  .RequestType  - N®tworkManagerR®quest  THEN 
CASE  IORequestA.ChainA.NumberOf Trans actions  OF 


Is 


LoadTim®  RequestPro cessing  + ChainProc«ssingOv®rh®ad 

+ ChainProceasinglTransaction; 


I 2: 


LoadTim®  RequastProcessing  + ChainProcassingOv®rh®ad 
+ ChainP roc®s a ing2 Transact ions; 


I 4,* 18: 

(*  This  handle  talker  out  of  turn  request  during 
network  growth.  *) 

LoadTim®  :»  Request  Pro  cessing  + ChainP  roc®asingOv®rh®ad; 

END; 

ELSIF  IORequestA  .Request Type  - MonitorForFault  THEN 
LoadTim®  : - 0.0; 

END; 

RETURN (LoadTim®) ; 

END  ComputelOLoadTime; 

(************************ t********* ************* *** ****** ******************* 

PROCEDURE  Compute I OUnloadTimo (IORosponse  : IOResponaeType)  :REAL; 

VAR  UnloadTime  : REAL; 

BEGIN 

IF  IOR®spons®A  .RosponseTyp®  - ApplicationResponse  THEN 
CASE  IORaaponseA . Identifier  OF 
100: 


UnloadTime 
I 50: 

UnloadTime 

| 25: 


(2.0  * EndOfChainProcessingOverhead)  + EndOfChainProcessinglOOHz 
(2.0  * EndOfChainProcessingOverhead)  + EndOfChainProcessing50Hz; 


UnloadTime  (2.0  * 


EndOfChainProcessingOverhead)  + EndOfChainProceaaing25Hz; 


END; 

WITH  IOResponseA  DO 

IT  NOT  ( (ResponseArray [ X]  <>  NIL)  AND  (ResponseArray [2]  <>  NIL))  THEN 

(*  Cut  unload  time  in  half  since  only  one  network 
is  in  sarvica.  *) 

UnloadTime  :■  0.5  * UnloadTime; 

END ; 

END; 

ELSIT  IORasponse*.ResponseType  - NetworkManagerResponse  THEN 
CASE  QSire  (IOResponse''  .Response* . InputFrameQueue)  OF 
1: 

UnloadTime  EndOfChainProcessingOverhead  + EndOfChainProcessinglTransaction; 

I 2: 

UnloadTime  EndOfChainProcessingOvarhaad  + EndOfChainProcessing2Transactions 

I 4,  18: 

(*  This  handle  talker  out  of  turn  request  during 

UnloadTime  ?-°EndOfChainProceaaingOverhead  + EndOfChainProcessingMonxtor; 

END; 

ELSIF  IOReaponaaA . ResponseType  - FaultMonitorResponae  THEN 

UnloadTime  EndOfChainProceaaingOverhead  + EndOfChainProceasingMonitor; 


END; 

RETURN  (UnloadTime  + ResponseCompletionProcessing) ; 


END  Compute IOUnloadTime; 

i*,********.******************************************************!********’ 

(*  Check  to  make  sura  chain  on  network  2 executed  without  error . « no*' 
take  the  ^twork  2 out  of  service  and  schedule  a monitor  for  fault  chain 
ifthe  reconfiguration  strategy  is  on.  shot  repair,  otherwise  have 

the  network  manager  regrow  network  2.  *)  Tnn»«rv«n»eTvoa • 

PROCEDURE  CheckNetworksForFault (Response  : IOResponaeType,_ 


J,  L ’ 

TAeAwl  ahaTimal 


VAR  FaultCheckRequest 

DataCollectionRecord 
Regr owNetvor kRequ  e s t 
FaultMonitorProceasing 
Process ingFaultMonit or 
RegrowNetworkProcesa ing 
p rocess ingRegr ovNetwork 


: DataPointer; 

: DataElementType ; 

: NetworkManagerServiceRequest; 

: DataPointer; 

: ProceasingUnit; 

: DataPointer; 

; ProcessingUnit; 


BEGIN 

IF  (ServiceState.NetworkHealth [2]  - InService) 
AND  (ResponseA . ChainStatus [ 2 ] - 
CommunicationFault)  THEN 


ServiceState . NetworkHealth [ 2 ] 
NetworkOutOfServiceTime [2] 

REPORT  "%12.8f"  clock  TAGGED 


OutOf Service; 
clock; 

"Network  Out  of  Service  at 


n * 


REPORT  "%d"  NetworkCounter  TAGGED  "The  network  with  the  failure  is 

DataCollectionRecord. Event ID  28; 

DataCollectionRecord. SimulationTime  :»  clock; 

DataCollectionRecord. Frequency  NonCyciic; 

DataCollectionRecord .NonCyclicData .N_Variation  NetServiceChange; 

DataCollectionRecord .NonCyclicData .NetworkID  :-2; 

Wr it eDataE lament Type (DataCollectionRecord) ; 

IF  StrategyForRec on figuration  - 0 THEN 

REPORT  "%12 . 8f  " clock  TAGGED  "Application  Chain  Fault"; 

NEN(FaultMonitorProceaaing) ; 

FaultMonitorProce«singA .Function  StartFaultMonitor; 

NEW (ProcesaingFaultMonitor ) ; 

WITH  ProceaaingFaultMonitorA  DO 

Priority  IOSyst^nServicePriority; 

ProcassingRequired  ;*  RequeatProcaasing  + ChainProcessingOverhead; 
WriteData  FALSE; 

ProcesalD  'Fault  MonitorPr oca as ing' ; 

Data  FaultMonitorProcessing; 


END; 

NOW  outport [IOPPort] A .ProceaaorRequeat  <-  ProceaaingFaultMonitor; 


ELSE 


IOServiceState . ActiveRootLink [ 2 ] IONetworkConnections [2] . 

NetworkConnections {2} .GPCAddresa; 

NEW (RegrowNetworkRequeat) ; 

NEW (RegrowNetworkRequeat) ; 

WITH  RegrowNetworkRequeat A DO 

ServiceRequest  :■»  GrowNetwork; 

ActiveRootLink  IOServiceState  .ActiveRootLink [2]; 


END; 

IONetworkConnectiona (2 ] .ConnectionStatua [2 ] Active; 

NEW (RegrowNetworkProcea sing) ; 

RegrowNetworkProcessingA .Function  NetworkRepa ir ; 

RegrowNetworkProcea  a ingA  .RepairData  RegrowNetworkRequeat; 

NEW(ProcessingRegrowNetwork) ; 

WITH  ProcQ3singRegrowNetworkA  DO 

Priority  IOSyateaServicePriority; 

ProcessingRequired  0.0; 

WriteData  FALSE; 

ProcesalD  'Regrow  Network  Processing'; 

Data  RegrowNetworkProcea sing; 


END; 

NOW  outport [ IOPPort ]A. ProceaaorRequeat  <-  ProcessingRegrowNetwork; 


END; 

ELSIF  (ServiceState .NetworkHealth ( 1]  - InService) 

AND  (ReaponaeA .ChainStatus [1]  - CommunicationFault)  THEN 

WriteString (ParamOut,  "Unexpected  fault  found  in  network  1."); 
WriteLn (ParamOut) ; 


ELSE 
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(*  Either  the  network  is  already  out  of  service,  or  no 
communication  faults  oc cured.  In  either  case  there  is 
nothing  to  do.  * ) 

END, 


END  CheckNetworksForFault ; 

/a*************************************************************************) 

* This  procedure  computes  the  time  to  load  the  I/O  request  on  the 
network (s)  that  are  in  service,  starts  the  chains,  and  schedules 
the  I/O  completion  poll.  *) 

PROCEDURE  ExecuteApplicationRequest  (IORequeat  : IORequestType; 


» 

Trt&ArvicaStateTvDe) i 


VAR  Semaphore  : SemaphoreType; 

Semaphores tatus  : INTEGER; 

Interface  ID  : INTEGER; 

NetworkCounter  : INTEGER; 

LoadRequest  : RequestExecutionStatus ; 

BEGIN 


NEW (LoadRequest) ; 

LoadRequest*. Request  IORequest; 

LoadRequestA.RequestType  ApplicationRequest; 

FOR  NetworkCounter  1 TO  NumberOfNetworka  DO 

IF  ( SarviceStata . Natwor kHaalth [NatworkCountar]  - InSarvice)  THEN 

(*  Daternina  th#  activa  interface  for  the  network  that  this 
request  will  execute  on.  *) 

Interfaced  ServiceState. ActiveRootLink (NetworkCounter] ; 

LoadRequest A . P or tAr ray  (NetworkCounter]  GetOutPort  (Interfaced) 

(*  Mark  network  loaded  with  a chain.  M 
LoadRequest A.ExecutingOn [NetworkCounter]  TRUE; 


ELSE 


(*  Mark  network  not  loaded  with  a chain. 
LoadRequest A .ExecutingOn [NetworkCounter] 


*) 

!*  F ALSE ; 


END; 


END; 

(*  Make  a request  for  the  I/O  system  semaphore,  if  the  semaphore 
is  idle,  the  request  will  be  executed.  Otherwise,  if  no  other 
request  of  the  same  priority  is  waiting,  the  current  request 
will  be  pended  for  later  execution.  If  a request  of  the  same 
priority  is  waiting,  the  current  request  will  be  ignored.  ) 

NEW (Semaphore) ? . . 

Semaphore A .Priority  IORequest  .Priority; 

Semaphore* . ExecutionStatus  LoadRequest; 

SamaphoreStatus  :«  Request (Semaphore) ; 

IF  (Semaphores tatus  - SemaphoreGranted)  THEN 

StartlOSs (LoadRequest,  ServiceState) ; 

DISPOSE (Semaphore) ; 


END; 

END  ExecuteApplicationRequest; 

(..*«.*.*******************************************************************) 

PROCEDURE  ExecutaManager2Ra<guest (IORaquest  : IORaqueatType ; 

SarvicaStata  : IOSarvicaStateTypa) ; 


CONST  Network2 ID 


- 2; 


VAR  TimeToLoadRequest  : REAL; 

InterfacelD  : INTEGER; 

Exacu t io nRequea t : RequestExecutionStatus; 

LoadlOProcesaing  : DataPointer; 

BEGIN 

{*  This  oust  is  a request  for  a network  that  is  out  of  service, 
Network  Manager  chain  or  Monitor  for  fault  chain.  The  status 
of  the  network  is  assumed  out  of  service  and  no  other  chain 
is  pending  on  this  network.  *) 

(*  Determine  the  active  interface  for  the  network  that  this 
request  will  execute  on.  *) 

Inter facelD  : - ServiceState . Act iveRootLink (Network2 ID ] ; 

(*  Compute  the  time  to  load  this  request  in  the  DPM  through 
the  Data  Exchange.  *) 

TimeToLoadRequest  Compute IOLoadTime{ I ORequest,  ServiceState) ; 

NEW (ExecutionRequest) ; 

ExecutionRequestA. Request  :»  IORequest; 

ExecutionRequest*  .RequestType  : » I ORequest A .Request Type; 

ExecutionRequest A . Port  GetOutPort ( Interface ID) ; 

Start IOSs (ExecutionRequest,  ServiceState) ; 

END  ExecuteManager2Request; 

PROCEDURE  UnloadResponse (RequestToService  : RequestExecutionStatus; 

ServiceState  : IOServiceStateType; 

VAR  Data  : (JnloadRequestType) ; 

VAR  NetworkCounter  : INTEGER; 

InterfacelD  : INTEGER; 


BEGIN 

NEW (Data. Response) ; 

IF  RequestToService* . Request A . RequestType  - ApplicationReguest  THEN 

Data .ResponseType  : - ApplicationResponse; 

Data. Response A .Response Type  ApplicationResponse; 

Data. Re spo nse A . Identifier  RequestToServiceA.RequestA.Identifier* 

Data. Response*. Frame  RequestToService* .Request* .Frame; 

( Only  unload  those  network (s)  executing  a request.  *) 

FOR  NetworkCounter  1 TO  Number OfNetworks  DO 

IF  RequestToService * .ExecutingOn (NetworkCounter]  THEN 

(*  This  is  set  to  force  Request  Completion  processing 
to  process  this  chain.  Request  completion 
processing  will  set  this  to  the  proper  value.  *) 

Data . Response A . ChainStatus [NetworkCounter ] : - NoFaults ; 

{*  Determine  the  active  interface  for  the  network 
that  this  request  was  executing  on.  *) 

InterfacelD  : - ServiceState . ActiveRootLink [NetworkCounter] ; 

WITH  Data .Response*  DO 

ResponseArray [NetworkCounter]  :«  inport [Get InPort ( 
InterfacelD) ] * .DataFromlOS; 

IF  inport [GetlnPort (InterfacelD) ] * .ChainCompleted  THEN 
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{*  Chain  Completed  normally.  *) 

ReaponaeArray  [NetworkCounter]  A .ChainTimeOut Indicator 
:»  NormalCcmpletion; 


ELSE 


(*  chain  has  timed  out.  Command  IOS  to  stop 
execution  and  unload  chain.  *) 

Respona  eArray  [Networ kCounter  ] A .ChainTimeOut Indicat or 
TimedOut; 

NOW  outport [GetOutPort (IntarfacalD) ] A .StopIOS  <-  TRUE; 


END ; 


END; 


ELSE 

Data.RaaponaaA . ChainStatua [NetworkCountar]  NotExecuted; 

Data. Ra ap onseA .Raspona eArray [NetworkCountar]  NIL; 


END; 


END; 


ELSE 

IF  RaquaatToSarvicaA  .RaquaatTypa  - NetworkManagerRequest  THEN 

Data . RaaponaaTypa  : - NetworkManagerResponse; 

Data.RasponsaA . RasponsaTypa  NatworkManagarRasponse ; 


ELSE 


Data. RasponsaTypa  im  FaultMonitorResponse; 

Data. Response A .RasponsaTypa  FaultMonitorResponse; 


END; 


(*  Unload  the  request  *) 
IntarfacalD 

Data .Response A .Response 


ServiceState . ActiveRootLink [NatworkID2 ] ; 
inport [GatlnPort (IntarfacalD) ] A . DataFroalOS 


IF  inport [GatlnPort ( IntarfacalD) ] A .ChainCompleted  THEN 

Data . Response  A . Response  * . ChainTimeOut Indicator  : - NoraalCompletion 


ELSE 

Data. Response*. Response*. ChainTimeOutlndicator  TimedOut; 

NOW  outport [GetOutPort (IntarfacalD) ] A .StopIOS  <-  TRUE; 


END; 


END; 


END  UnloadRasponsa ; 
{***************** ******* 


**★******★****************************************) 


PROCEDURE  Start IOSs (RequestToLoad  : RequastExecutionStatus; 

ServiceState  : IOServiceStateType) ; 


CONST  OnaMi  Hi  Second  - 0.001; 

VAR  NatworkCounter  : INTEGER; 

BitTimeToNextMi lli Second  : REAL; 


BEGIN 


WITH  RequestToLoadA  DO 


IF  Request Type  - ApplicationRequest  THEN 

REPORT  "%d"  Requests  Identifier  TAGGED  "Start  Network  Activity"; 

FOR  NetworkCounter  1 TO  NumberOfNetworks  DO 

IF  ExecutingOn [NetworkCounter]  THEN 

IF  ServiceState .NetworkHealth [NetworkCounter]  ■ InService  THEN 

NON  outport [PortArray [NetworkCounter] ] A . ChainToIOS 
<-  Request A . ChainArray [NetworkCounter] ; 

ELSE 


{*  This  chain  was  loaded  when  network  waa 
in  service,  but  has  gone  out  of  service 
before  the  chain  could  begin  execution.  *) 
ExecutingOn [NetworkCounter]  FALSE; 


END; 


END; 


END; 

ELSE 


NOW  outport [Port] A. ChainToIOS  <-  RequestA .Chain; 


END; 


BitTiaeToNextMilliSecond  OneMilliSecond  - RaalMod (clock,  OneMilliSecond) ; 
AFTER  (BitTjjneToNextMilliSecond  + Request A . RequestTimeoutValue) 
IOCompletionPoll  <-  Request To Load; 


END; 

END  Start IOSs; 

( **************  *************  ***  ***********************  *********************} 
BEGIN 

NetworkManager2Port  GetOutPort  {Manage rIDNetwork2)  ; 

ApplicationPort [1]  GetOutPort (ApplicationID [ 1] ) ; 

ApplicationPort  [2]  GetOutPort (ApplicationID [2] ) ; 

ApplicationPort ( 3 ] GetOutPort (ApplicationID [3] ) ; 

IOPPort  GetOutPort (IOP Identifier) ; 

ControlsPort  GetOutPort (Controls Identifier ) ; 

(*  Request  IOP  to  complete  Power  Up  Initialization.  *) 

NEW (PowerUpProcea sing) ; 

WITH  PowerUpProceasingA  DO 

Function  PowerUp; 


END; 

NEW  (PowerUpRequest ) ; 

WITH  PowerUpRequest A DO 

Priority  :»  IOSystemServicePriority; 

Process ingRequired  Poweruplntialize; 

WriteData  : * FALSE ; 

ProcessID  f IOServicePoverUp' ; 

Data  PowerUpProcessing;’ 

END; 

NOW  outport [IOPPort] A .ProcessorRequest  <-  PowerUpRequest; 
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WAITUNTIL  (Process orResponse) 

Process orResponse : 

ProceaaReaponae  ActivePort* .ProcassorRasponsa; 

NetworkData  : - ProceaaReaponae* . Data; 

WITH  NetworkDataA  DO 

IF  Function  - Power Up  THEN 

NOW  InitializeService  <-  TRUE; 

EXIT; 

ELSE 

WriteString  (ParamOut,  "Problem  during  powar  up  procaaamg. 
Wr iteLn (ParanOut) ; 


END; 


END; 


END; 

DISPOSE (Net workDat a) ; 
DISPOSE (Pro cess Response) ; 


END; 

(*  Thia  loop  waita  for  tha  initialiia  aervice  raquaat.  Thia  raquaat 
would  happen  at  power  up  in  a flight  system.  ) 

LOOP 


WAITUNTIL  (InitializeService) 


InitializeService: 


/t  Find  out  how  many  IOSfs  each  network  has. 
FindlOSConnections (1,  IONetworkConnections [1] 
FindlOSConnections (2,  IONetworkConnections [2] 


*) 

.NetworkConnections) ; 
.NetworkConnections) ; 


(*  Initialize  all  network  connections  to  idle. 

FOR  NetworkCounter  1 TO  NumberOfNetworks  DO 

FOR  InterfaceCounter  1 TO  NumberOf IOSPerChannel  DO 


IF 


IONetworkConnections [NetworkCounter) . _ 

NetworkConnections [InterfaceCounter] .GPCAddres 


s 


<>  0 THEN 


IONetworkConnections [NetworkCounter] . 

ConnectionStatus [InterfaceCounter]  Idle 


ELSE 

(*  This  simulation  run  does  not  have  an  interface 
with  this  ID,  set  its  status  to  failed.  *) 

IONetworkConnections [NetworkCounter] . 

ConnectionStatus [InterfaceCounter]  Failed; 


END; 


END; 


END; 

(*  Initialize  Active  intarfacaa.  Since  all  hardware  should 


fc*  "good",  the  first  interface  will  be  used.  *) 

IONetworkConnect  ions  [1]  .ConnectionStatus  [1] 
IONetworkConnections  [2]  .ConnectionStatus  [1] 

IOServiceS  tat  e . Me  twor  kHeal  th  { 1 ] 

IOServiceStat e . NetworkHealth ( 2 ] 

IOServiceS tate .ActiveRootLink [1] 

IOServiceS tate .ActiveRootLink [2] 

IOServiceState .ExecutinglOOHz 
IOServiceState .Executing50Hz 
IOServiceState . Executing25Hz 

(*  Create  chain  to  monitor  network  2 for  faults.  *) 
ReadNodelnterConnections (2,  Network2Connectiona) ; 
FaultMonitor2  MakeMonitorRequast (Network2Connections) ; 

WITH  FaultMonitor2A  DO 


- Active; 

- In Service; 

- In Service ; 

^tW°r!!ConndCti0n3  ^ ^ .NetworkConnections  f 1 ] . GPCAddress 
IONatwrxConn«ctioD3[2]  -NetworkConnections  [1]  .GPCAddress 
m FALSE; 

- FALSE; 


Identifier  302; 

Priority  1; 

ResponseExpected  TRUE; 

RequestType  MonitorForFault; 

Chain A .NetworkToBaExecutedOn  2; 

Chain A .Chain Identifier  302; 


END; 


(*  Notify  controller  that  the  networks  are  available  to  use  *) 
NOW  outport [ControlsPort] A . ServiceAvailable  <-  TRUE- 

WYT'T'  • f 


END; 


END; 

LOOP 

WAITUNTIL  EVENT 

IOServiceRequest : 

ServiceRequest  Act ivePort A . IOServiceRequest; 

IF  ServiceRequest A . OnDemand  THEN 

OnDemandRequestDelay  Random (1,  0.000020,  0.000035); 

ELSE 

OnDemandRequestDelay  0.0; 


END; 

IF  (ServiceRequestA .RequestType  - ApplicationRequest)  AND 
(ServiceRequest A .Priority  - 10)  AND 
NOT  IOServiceState .ExecutinglOOHz  THEN 

SAMPLE  1.0  WITH  SystemProbe  [ProbeNumber]  ; 

IOServiceState. ExecutinglOOHz  TRUE; 

RequestTime  Compute IOLoadTime (ServiceRequest, IOServiceState) 
+ OnDemandRequestDelay  + Requestprocessing; 

NEW(ProcessRequest) ; 

WITH  Process Request A DO 

Function  :*  IORequestSchedule; 

IORequest  :=  ServiceRequest; 


END; 

SubmitRequestProcessing(ProcessRequest , 

NOT  ServiceRequest ' .OnDemand,  ServiceRequest'1. Frame, 
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RaquestTiae,  SarvicaRaquast A .Priority) ; 

ELSIF  (SarvicaRaquast* .RaquastTypa  - ApplicationRaquest)  AND 
(ServiceRequestA. Priority  - 9)  AND 
NOT  IOSarvicaStata .Executing 5 0Hz  THEN 

SAMPLE  1.0  WITH  SyatemProbelProbeNumber] ; 


IOSarvicaStata . ExecutingSOHz  :■  TRUE, 

RaquastTima  Compute I OLoadTime  (SarvicaRaquast,  IOSarvicaStata) 

<*U  j.  + Requestprocessing, 


NEW(ProcessRequest) ; 

WITH  Process Request A DO 

Function  IORequestSchedule; 

IORequest  ServiceRequest; 


END; 

SubmitRequestProceasing (ProcessRequest,  _ 

NOT  ServiceRequest* .OnDemand,  SarvicaRaquast  Frame, 
RequeatTime,  SarvicaRaquast* .Priority) ; 

ELSIF  (SarvicaRaquast* .RequestType  - ApplicationRaquest)  AND 
(SarvicaRaquast* .Priority  m 8)  AND 
NOT  IOSarvicaStata . Exacut ing 2 5Hr  THEN 

SAMPLE  1.0  WITH  SystemProbe [ProbeNumber ] ; 

IOSarvicaStata. Executing25Hi  TRUE; 

RaquastTima  Compute IOLoadTime  (SarvicaRaquast,  IOSarvicaStata) 
Requestrim  + 0n^4ndRBquastD<,uy  + Requestprocessing; 


NEW (ProcessRequest) ; 

WITH  ProceasRaquestA  DO 

Function  :•  IORequestSchedule; 
IORequest  ServiceRequest; 


END; 


SubmitRequestProcessing  (ProcessRequest, 

NOT  ServiceRequest*  .OnDemand,  SarvicaRaquast  .Frame, 
RaouestTime,  SarvicaRaquast  .Priority), 


ELSIF  SarvicaRaquast* .RaquastTypa  - NatvorkManagarRequast  THEN 

RaquastTima  Confute IOLoadTima (SarvicaRaquast, IOSarvicaStata) 

NEW (ProcessRequest) ; 

WITH  ProcessRequestA  DO 

Function  IORequestSchedule; 

IORequest  ServiceRequest; 


END; 

SubmitRaquestProcessing (ProcessRequast,  FALSE,  0,  RaquastTima, 
SarvicaRaquast A .Priority) ; 


END; 


IOCompletionPoll : 


RaquestToServica  :« 
IF  RaquestToServica 


IOCompletionPoll; 

A .Request A .ResponseExpected  THEN 


zssssgssrzs^^ 


IF  RaquestToServica*. RaquastTypa  - ApplicationRaquest  THEN 


(*  1/27/88  *) 
(*  1/27/88  *) 
(*  1/27/88  *) 


ResponseCompletion  (ResponsaData .Response) ; 

CheckNetworksForFault  (ResponsaData  .Response, 

IOSarvicaStata) ; 

(*  Ralaasa  semaphore  and  check  for  a highar  priority 
raquast  that  ia  waiting  for  start  I OS.  *) 

Ralaasa (PandingStatus ) ; 

IF  PandingStatus  > RequestToServiceA .Requests Priority  THEN 
NEW (Pending IOProcaa sing) ; 

PandingIOProcasaingA. Function  StartPandinglO; 

NextRequest (PandingRaquast) ; 

P*ndingIOProc*s»ingA .RaquestStatus  PandingRaquast* .Execution Status; 

DISPOSE (PandingRaquast) ; 

NEW (Process ingStartPandinglO) ; 

WITH  ProcassingStartPandingIOA  DO 

Priority  :»  PandingStatus; 

Process ingRaquirad  0.0; 

WritaData  FALSE; 

Process  ID  'Start  Pending  I/O'; 

Data  :■  PandinglOProceaaing; 


END; 

NOW  outport [IOPPort] A .ProcaasorRaqueat  <-  ProceasingStartPandinglO; 

END ; 

NEW(Raapon3aDataProcassing) ; 

WITH  RasponsaDataProcessingA  DO 

Function  :«  IORasponsaSchedule; 

IORasponsa  :•  RasponsaData.Raaponae; 


END; 

SubmitUnloadlORaquaat  (ResponseDataProcessing, 

TimeToUnloadRaquest,  RequaatToSarvice A .Request A .Priority) ; 

ELSIF  RequastToSarvicaA .RaquastTypa  - NetworkManagerRequeat  THEN 

NEW(RasponsaDataProcassing) ; 

WITH  RasponaaDataProcassingA  DO 

Function  IORasponsaSchedule; 

IORasponsa  RasponseData. Response; 


END; 

SubmitUnloadlORequest  { Re spon a eDataPro cessing, 

TimeToUnloadRaquest,  Raquast To Sar vice A. Request A .Priority) ; 

ELSIF  RaquastToSarvicaA .RaquastTypa  - MonitorForFault  THEN 

IF  Re sponseData. Re sponseA .Response A .AllFailad  THEN 

NEW (ServiceNetworkRaquest) ; 

WITH  ServicaNetworkRequestA  DO 

SarviceRequest  SwitchRootLink; 

(*  This  section  of  coda  uses  internal  workings 
of  DENET  to  determine  the  FailedRootNode . 

IT  IS  CONFIGURATION  DEPENDANT.  *) 

CurrentNodelD  :«  IOServiceState.ActivaRootLink{2] ; 

FailedRootNode  GetOutNode (2) ; 

CurrentNodelD  MyNodelD; 

FailedRoot Number  : - FailRootLink ( IONetworkConnections (NetworkID2 ] , 
IOServiceState . ActiveRootLink [NetworkID2 ] ) ; 
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IOSarviceState . ActivaRootLink |NetworkID2] 

: - SwitchRootLinks  ( IONetworkConnections  (NetworkID2  ] , 

NetworkID2,  FailadRootNumber) ; 

IF  IOSarviceState. ActivaRootLink [NetworkID2]  • 0 THEN 

(*  A good  root  link  cannot  be  found.  This 

network  will  not  ba  ra turned  to  service.  *) 

WriteString (ParamOut,  "Network  2 has  no  more  root  links."); 

WritaLn  (ParamOut) ; 

WriteString (ParamOut,  "Continue  oparation  with  Network  2 out  of  sarvica.  ) 
WritaLn (ParamOut) ; 


END; 


(*  This  section  of  coda  uses  internal  workings 
of  DENET  to  determine  the  FailedRootNode . 

IT  IS  CONFIGURATION  DEPENDANT.  *) 

CurrentNodelD  IOServicaState. ActivaRootLink  [2] ; 
NawRootNoda  GatOutNode  (2)  ; 

CurrentNodelD  MyNodalD; 


END; 

(*  Make  a request  to  the  IOP  for  execution  time 
to  switch  root  links.  *) 

NEW (RootLinkSwitchPr ocas sing) ; 

RootLinkSwitchProcessingA .Function  NetworkRepair; 

RootLinkSwitchProcessingA .RopairData  ServiceNetworkRequest; 

NEW {ProcassingNatworkRapair ) ; 

WITH  ProcessingNatworkRapairA  DO 

Priority  IOSystamSarvicaPriority; 

Process ingRequired  Tla*To0nloadR»qu»8t  + SwitchRootLinkProcassing; 

WriteData  FALSE; 

ProcassID  'Switch  Root  Link  Processing'; 

Data  5“  RootLinkSwitchProcessing; 


END; 

ReleaseChainResponseMemory  (RasponsaData . RasponseA . Response) , 
DISPOSE (RasponsaData. Response) ; (*  PRB  *) 


ELSE 


NEW  (ServiceNetworkRequest) ; 

WITH  ServiceNetworkRequest  DO 

ServiceRequest  • m RapairFault; 

MonitorChainResponsa  RasponsaData. Response; 


END; 

NEW ( Rep airNatworkPr ocas sing) ; 

RepairNatworkProcassingA .Function  NetworkRepair; 

Rapa irN a two rkP roc as singA .RepairData  ServiceNetworkRequest; 

NEW (ProcassingNatworkRapair) ; 

WITH  Process ingNetworkRepairA  DO 

Priority  :*  IOSystamSarvicaPriority; 

ProcassingRaquired  :«  TimaToUnloadRaquast; 

- FALSE; 

- 'Repair  Network  Processing'; 

- RepairNetworkProcessing; 


WriteData 

ProcassID 

Data 


END; 


END; 
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NOW  outport [IOPPort] A .Processor Request  <-  ProcessingNetworkRepair; 


END  f 

ELSE 


(*  1/27/88  *) 


(*  1/27/88  *) 
(*  1/27/88  ») 
(*  1/27/88  *) 


(*  The  request  for  this  poll  just  contains  output 
transactions  with  no  input  transactions,  check 
for  any  pending  request  that  is  higher  priority.  *) 

(*  Deleted  Lines  *) 

(*  Release  semaphore  and  check  for  a higher  priority 
request  that  is  waiting  for  start  IOS.  *) 

Release (PendingStatus) ; 

IF  PendingStatus  > Reques tTo Service A .Request A .Priority  THEN 
NEW  (P ending IOProces sing) ; 

PendingIGProcessingA .Function  StartPendinglO; 

NextRequest (PendingRequest) ; 

PendingIOProcessingA.RequestStatus  :•  PendingRequest A,ExecutionStatus; 
DISPOSE (PendingRequest) ; 

NEW  (Process ingStartPendinglO) ; 

WITH  ProcessingStartPendingIOA  DO 

Priority  PendingStatus; 

ProcesaingRequired  0.0; 

WriteData  FALSE; 

Process  ID  'Start  Pending  I/O'; 

Data  :«  PendinglOPr ocas sing; 


END; 

NOW  outport [IOPPort] A .Process or Request  <-  ProcessingStartPendinglO; 


END; 

NEW  (Re spo n s eDataPro cessing) ; 

WITH  ResponseDataProcessingA  DO 

Function  OutputResponseSchedule; 

Rate  Reques tTo Service A .Request A .Identifier; 


END; 

NEW(ProcessingOutputResponse) ; 

WITH  Process ingOutputResponseA  DO 

Priority  :«  RequestToService A. Request A. Prior ity; 

IF  ( IOServi ceState . NetworkHealth [ 1 j - InService)  AND 
(IOServiceState.NetworkHealth [2]  - InService)  THEN 

ProcesaingRequired  Response Comp let ionProcessing 

+ (2.0  * EndOfChainProcessingOverhead) ; 


ELSE 


ProcessingRaquired  :■  ResponseComplet ionProcessing 
+ EndOfChainProcessingOverhead; 


END; 

WriteData 

ProcessID 

Data 


- FALSE; 

- 'Output  Repsonse  Processing'; 
* ResponseDataProcessing; 


END; 

NOW  outport ( IOPPort ] A .ProcessorRequest  <-  ProcessingOutputResponse; 


END; 
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DISPOSE (RequestToService) ; (*  PRB  *) 


| RtnNetworkToSer vice : 

(*  This  avant  is  usad  to  raturn  network  2 to  service 
after  the  NetworkManager  has  repaired  it.  ) 


NewNetworkState  ActivePort* .RtnNatworkToSarvica; 


DataCollectionRecord. Event ID 
DataCollectionRecord . SiaulationTime 
DataCollectionRecord. Frequency 

DataCollectionRecord.NonCyclicData.N_Variation 

DataCollectionRecord  .NonCyclicData  .NetworkID 


29; 

clock; 

NonCyclic; 

NetServiceChange ; 
NewNetworkState A .NetworkID; 


WriteDataElementType (DataCollactionRacord) ; 


WITH  NewNetworkStateA  DO 


FaultMonitor2 A . Chain  MonitorChain; 
FaultMonitor2 A . RequestTimeoutValue  : - 
QSiza (FaultMonitor2A .Chain 


CooiputaChainT  imeout  ( 0 , 
A . Transact ionQueue) ) ; 


TineNetworkOutOf Service  clock  - NetworkOutOfServiceT^e  [NetworkID]  ; 

Wr iteStr ing^Paxa®Out , " Network  2 was  out  of  sarvica  for  "); 

WritaReal  {ParamOut,  TimeNetworkOutOf  Sarvica,  0), 

WritaString (ParamOut,  " seconds.”); 

WritaLn (ParamOut) ; 

WritaLn (ParamOut) ; 


IOSarviceStata  .NatworkHaalth  [NetworkID ] *nS^;c*; 

NON  outport [ControlsPort] A . SarvicaAvailabla  <-  TOTE, 


END; 

DISPOSE (NewNetworkState) ; (*  PRB  *) 

| processorResponse: 

ProcessResponse  ActivaPortA .ProcessorResponse; 

NotworkData  ProcessResponse-*  .Data; 

WITH  NatworkDataA  DO 

CASE  Function  OF 

IORequestSchedule : 

IF  IORaquast A . RaquestTypa  - ApplicationRequest  THEN 

ExecuteApplicationRequest (IORequest,  IOSarviceStata) ; 

ELSE 

ExecuteManager2Request (IORequest,  IOSarviceStata) ; 


END; 

| IOResponseSchedule: 

IF  I ©Response* .Re sponseType  - ApplicationRasponsa  THEN 

REPORT  »%d"  IORasponsa^. Identifier  TAGGED  "Finish  IOP  Activity" 

CASE  IORasponsaA .Identifier  OF 

100:  NOW  outport [ApplicationPort [1) }A- 

ApplicationResponse  <-  IORasponsa; 

IOSarviceStata. ExecutinglOOHz  FALSE; 


I 50:  HOW  outport  [ApplieationPort [2 J ] A. 

ApplicationRasponse  <-  IOResponae; 
IOSarvicaState  .ExecutingSOHz  FALSE; 

I 25:  NOW  outport [ApplieationPort [3 ] ] A . 

ApplicationRasponse  <-  IQRasponse; 
IOSarvicaState .Executing25Hz  FALSE; 


END; 

IF  (NOT  IOServiceState.ExecutinglOOHz)  AND 
(NOT  I OS* rvi cast at© .ExecutingSOHz)  AND 
(NOT  IOSarvicaState .Executing25Hz)  THEN 

SAMPLE  0.0  WITH  SystamProbe [ProbeNumber] ; 


(*  1/27/88  *) 
(*  1/27/88  *) 
(*  1/27/88  *) 
(*  1/27/88  *) 
(*  1/27/88  *) 
<*  1/27/88  *) 


(*  1/27/88  *) 
(*  1/27/88  *) 
(*  1/27/88  *) 


END; 

( * Check  for  any  pending  requests.  *) 

Semaphoreldl* (IOSystamStatus) ; 

IF  IOSystamStatus  THEN 

Release (PandingStatus) ; 

IF  (PandingStatus  - 10}  OR 

( (PandingStatus  - 9)  AND 

(NOT  IOSarvicaState  .ExecutinglOOHz) ) OR 

({PandingStatus  - 8)  AND 

(NOT  IOSarvicaState. ExecutinglOOHz)  AND 

(NOT  IOSarvicaState .ExecutingSOHz) ) THEN 

NEW (PandinglOProcas sing) ; 

PendingIOProceasingA. Function  StartPendinglO; 

NaxtRaquast  (PandingRaquaat) ; 3 

•~***^  ■**«*»**»' 

NEW (ProcessingStartPandinglO) ; 

WITH  Process ingStartPendingIOA  DO 

Priority  :«  PandingStatus; 

Process ingRequi red  :»  0.0; 

Writ ©Data  FALSE; 

ProcessID  :«  'Start  Pending  I/O'; 

s*  PandinglOProcas sing; 

END; 

NOW  outport [ IOPPort] A .Procassorltoquest  <-  ProcaaaingStartPandinglO; 

END; 


END; 


ELSE 


NOW  outport [NetworkManager2Port] A . 

IOManagar 2Rasponse  <-  IOResponsaA .Response ; 

IORasponse A . Response  NIL;  (*  MJS  *) 

DISPOSE (IOResponse) ; (*  pRB  *) 

END; 

I OutputResponseSchedul© : 

REPORT  %d  1 Rat©  TAGGED  "Finish  IOP  Activity”; 

CASE  Rate  OF 
100: 

IOSarvicaState .ExecutinglOOHz  FALSE; 
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IOSarvicaStata . Executing 5 OH z :*  FALSE; 


| 25: 


IOSarvicaStata .Executing25Hz  FALSE; 


END; 

IF  (NOT  IOSarvicaStata . ExacutinglOOHz ) AND 
(NOT  IOSarvicaStata .Executing 5 OH z)  AND 
(NOT  IOSarvicaStata. Exacuting25Hz)  THEN 

SAMPLE  0-0  WITH  SystemProbe (ProbeNumber]  ; 


END; 


(*  1/27/88  *) 
<*  1/27/88  *) 
<*  1/27/88  *) 
(*  1/27/88  *) 
(*  1/27/88  *) 
(*  1/27/88  *) 


(*  1/27/88  *) 
(*  1/27/88  *) 
(*  1/27/88  *) 


(*  1/27/88  *) 


(*  Check  for  any  ponding  requests.  *) 

Saoaphoreldle (IOSystamStatus) ; 

IF  IOSystemStatus  THEN 

Release (PandingStatus) ; 

IF  (PandingStatus  - 10)  OR 
((PandingStatus  - 9)  AND 
(NOT  IOSarvicaStata .ExacutinglOOHz) ) OR 
((PandingStatus  - 8)  AND 

(NOT  IOSarvicaStata .ExacutinglOOHz)  AND 
(NOT  IOSarvicaStata .ExacutingSOHz) ) THEN 


StartPendinglO; 


NEW(PandinglOProcassing) ; 

PendinglOProcessing* .Function 

PanSn^OProcessing'^RaquaatStatus  P«ndingR®qu«stA  .ExacutionStatus 

DISPOSE (PandingRaquast) ; 


NEW(ProcassingStartPandinglO) ; 
WITH  procassingStartPandingIOA  DO 


Priority 

ProcassingRaquirad 

WritaData 

ProcassID 

Data 


- PandingStatus; 

« 0.0; 

!-  FALSE; 

'Start  Ponding  I/O'; 
:»  PandinglOProcassing; 


END; 

NOW  outport [ IOPPort] A .ProcasaorRaqueat  <-  ProceaaingStartPandinglO; 


END; 


END; 

StartPendinglO : 

StartlOSa (Raquaat Status,  IOSarvicaStata) ; 
StartFaultMonitor : 

ExecuteManager2Raquast  (FaultMonitor2,  IOSarvicaStata) ; 

NotworkRapair : 


IF  NatworkData'1  .RapairDataA  .SarvicaRaquast  - 

SwitchRootLink  THEN 

WITH  DataCollectionRacord  DO 

EvantID  :»  29; 

S inula  tionTime  clock; 

Frequency  NonCyclic; 

NonCyc 1 icDat a . N_Var iat ion  NetServiceChange, 


NonCyclicData . NetworkID 


2; 


END; 

WriteDataElementType  (DataCollectionRecord) ; 

TimeNetvorkOutOf Service  clock  - NetworkC*it0fServiceTime[21 ; 

Nr i tain (ParamOut ) ; J 

WriteString (ParamOut,  " Network  2 was  out  of  service  for  "); 
WriteReal (ParamOut,  TimeNe two rkOutOf Service,  0); 

WriteString (ParamOut,  " seconds."); 

WriteLn (ParamOut) ; 

WriteLn (ParamOut) ; 

IOSarvicaStata .NatworkHaalth [2]  InService; 

NOW  outport [ControlsPort J A . SarvicaAvailabla  <-  TRUE; 


END; 

NOW  outport [NetworkManager2Port] A . 

Man agar SarvicaRqst  <-  NetworkDataA . RepairData ; 

ELSE 


Writ aSt ring (ParamOut, 
WritaLn (ParamOut) ; 


"Unexpected  Response  from  the  XOP  in  the  I/O  Service."); 


END; 


END; 


DISPOSE (NetworkData) ; 

DISPOSE (ProceasResponse) ; 

I Reset: 

Set Semaphore I die ; 

(*  ^initialize  all  network  connections  to  idle.  *) 

FOR  NetworkCounter  :■  1 TO  NumberOfNetworks  DO 

FOR  InterfaceCounter  1 TO  NumberOf IOSPerChannel  DO 

IF  IONatworkConnections [NetworkCounter] . 

NetworkConn act ions [InterfaceCounter] .GPCAddresa 
<>  0 THEN 

IONatworkConnections [NetworkCounter] . 

ConnectionStatus [InterfaceCounter]  :«  Idle; 

ELSE 


( * This  simulation  run  does  not  have  an  interface 
with  this  ID,  set  its  status  to  failed.  *) 

IONatworkConnections [NetworkCounter] . 

ConnectionStatus [ InterfaceCounter]  Failed; 

END; 


END; 


END; 


(*  Reinitialize  Active  interfaces.  Since  all  hardware  should 
be  "good",  the  first  interface  will  be  used.  *) 


IONatworkConnections [ 1 ] . ConnectionStatus [ 1 ] 
IONatworkConnections [2] .ConnectionStatus ( 1 ] 
IOSarvicaStata .NatworkHaalth [ 1 ] 
IOServiceState .NetworkHealth [2] 
IOServiceState . Act iveRootLink [ 1 ] 


- Active; 

- Active; 

- In Service; 

■»  InService; 

- IONatworkConnections [1] .NetworkConnections [ 1] .GPCAddres 
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IOSarvicaState . ActivaRootLink ( 2 ] 
IOSarvicaStata .ExacutinglOOHz 
IOSarvicaStata . Executing50Hz 
. IOSarvicaStata . Executing2  5Hz 


- IONatworkConnactions [ 2 ] .NetworkConnactiona  (1]  .GPCAddress 

- FALSE; 

- FALSE; 

- FALSE; 


| ProbaRasat: 

(*  chock  if  tho  io  system  is  busy  by  looking  at  the  last  sample  taken  with  the  probe 
*) 

XF  SyatamProba [ProbaNumbar  1 A • ProbaValua  ™ 1*0  THEN 

ClaarProba  {SyatamProba  [ProbaNumbar] ) ; 

SAMPLE  1.0  WITH  SyatamProba  [ProbaNumbar]; 


ELSE 

ClaarProba (SystamProba [ProbaNumbar] ) ; 
SAMPLE  0.0  WITH  SystamProba [ProbaNumbar ] ; 


END; 


END; 


END; 


END  IOSarvice. 
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UTILITIES 


DEFINITION  MODULE  Utilities; 


FROM  IOS  IMPORT  Chain Type,  Chain Status Data; 

FROM  BusMessag  IMPORT  PortNameType,  PortEnableRegister Type; 

FROM  TypeConat  IMPORT  ChannellDType,  StatusType,  NodeArrayType, 

NodeStatusArray , Port Statu a Array,  ChannelStatusRecord; 

EXPORT  QUALIFIED  ClearPortStatuaArray,  UpdateLinkStatus,  SetNodeStatusFailed, 
ConvertPortStatuaToEnable,  InitializeStatusVariables , 

Nodes InThisSimulat ion,  ComputeChainTimeout, 

ManagerChainUnloadT ime ; 


'tt^t*********************************************************************) 

(*  This  procedure  computes  the  time  element  to  perform  the  unloading 
of  a network  manager  chain  from  the  DPM  in  the  IOS  to  the  IGP . *) 

PROCEDURE  ManagerChainUnloadT ime (Response  : ChainStatusData)  ;REAL; 

^tl'I'ttKI'I'Htttt***********************************************************) 

(*  This  procedure  will  return  an  array  of  type  Port Status Array 
with  all  the  elements  set  to  IdlePort.  *) 

PROCEDURE  clearPortStatusArray (VAR  PortStatus  : PortStatus Array) ; 

(*****HHtt*H*tHH****m*****HOOt******H**»**H******mmH***H*) 


PROCEDURE  UpdateLinkStatus (VAR  StatusArray 

Spawn  ingNode 
Spawn ingPort 
TargetNode 
TargetPort 
Links tat us 


NodeStatusArray; 
INTEGER; 
PortNameType ; 
INTEGER; 
PortNameType; 
StatusType) ; 


,**************************************************************************> 

PROCEDURE  SetNodaStatusFailed (VAR  StatusArray  : NodeStatusArray; 

NetworkConn actions  : NodeArrayType; 

FailedNode  : INTEGER) ; 


I***************************************************** ********************** 

(*  This  procedure  takes  an  array  of  type  PortStatusArray  and 
converts  it  to  a PortEnableRegister . If  an  element  in  the 
PortStatusArray  is  Active  then  the  corresponding  element  m 
the  PortEnableRegister  is  set  to  Enabled,  otherwise  the 
element  is  set  to  Disabled.  *}  ^ _ . . 

PROCEDURE  Convert? ortStatusToEnable  (VAR  PortStatus  : PortStatusArray,  _ * 

VAR  EnableRegister  : PortEnableRegisterType) 


/At**************************************************************** ********) 

j*  This  procedure  will  initialize  the  variables  that  the  network  manager 
needs  to  maintain  the  network.  *) 


PROCEDURE  InitializeStatusVariables  (NodeConnections  : NodeArrayType; 

VAR  NodeStatus  : NodeStatusArray; 

VAR  Channels tatus  : Channels tatusRecord) ; 


z**************************************************************************) 
{*  This  procedure  will  read  the  node  connections  array  and  determine 
how  many  nodes  are  in  the  current  simulation.  This  number  will  be 
0 < Nodes InSimulat ion  <-  NumberOfNodes , *) 

PROCEDURE  Nodes InThis Simulation (NodeConnections  : NodeArrayType) 

: INTEGER; 

(***************************************i***********°*******t**t**0tt^**) 
(*  This  procedure  computes  the  time  to  execute  a chain  based  on  the 

number  of  normally  completing  transactions  and  transactions  actions 
that  time  out.  A time  is  also  included  that  represents  the  turn 
around  time  between  transactions  at  the  IOS.  *) 


PROCEDURE  ComputaChain Timeout (NormalCompletions  : INTEGER; 

Tijn^outConplations  : INTEGER)  :REAI; 

(********* tt *** **# ***************** ************* *************************** ) 

END  Utilities . 


UTILITIES 


IMPLQffiNTATION  MODULE  Utilities; 

FROM  BusMessag  IMPORT  BuaMessageType,  PortNaaeType, 

PortEnableRegisterType,  PortStateType,  Number OfPorts Per Node, 
NumbarOfNodes , MakeNodeCon  figuration  Command; 

FROM  TypeConst  IMPORT  Channel ID  Type,  StatuaType,  PortConf igurationType , 
NodeArrayType,  Node StatusAr ray,  PortStatusArray, 

Channe IS tatus Record,  NetworkEleaentType; 

FROM  CentralDB  IMPORT  FindNodeNuaber; 


FROM  IOS  IMPORT  ChainType,  ChainStatusData,  TransactionType, 
InputFrameType,  TimeOut Indicator Type; 

FROM  InOut  IMPORT  WriteLn,  WriteString,  WriteReal,  Writelnt; 

FROM  Storage  IMPORT  ALLOCATE; 


FROM  QueueM  IMPORT  InitQ,  QSize,  QInsert,  QSucc,  FirstQ; 
FROM  MathLibO  IMPORT  mod; 


CONST  TransactionTimeOut  - 0,000500 

FixedChainUnloadTime  - 0.000050 

DataKxchangeUnloadTlme  - 0.000004 

OneMilliSecond  - 0.001; 

ManagerDXResponseLength  - 13; 


(*  sec  *) 

(*  sec  *) 

(*  sec/byte  *) 

(*  bytes  *) 


(************* *********************** ************************  *******#ttlktt1kj 


PROCEDURE  ManagerChainUnloadTime (Response  : ChainStatusData)  :REAL; 


VAR  UnloadTime  : - REAL; 

TranaactionUnloadTime  : REAL; 
NumberOflnputFrames  : INTEGER; 


BEGIN 

NumberOflnputFrames  : - QSize (Response A . InputFrameQueue) ; 
TranaactionUnloadTime  :*■  FLOAT (NumberOflnputFrames  * 

ManagerDXResponseLength)  * 
DataExchangeUnloadTime ; 

UnloadTime  FixedChainUnloadTime  + TranaactionUnloadTime; 

RETURN (UnloadTime) ; 

END  ManagerChainUnloadTime; 

(*************************************  ^^^^^^^^^^^^^ 
(*  This  procedure  will  return  an  array  of  type  PortStatusArray 

with  all  the  elements  set  to  IdlePort.  *) 

PROCEDURE  ClearPortStatus Array (VAR  PortStatus  : PortStatusArray); 

VAR  Port Index  : PortNameTypa; 

BEGIN 

FOR  Port Index  :*  1 TO  NumberOfPortsPerNode  DO 

PortStatus [Port Index] .Status  Idle; 

PortStatus [Portlndex] .Direction  Inboard; 


END; 

END  ClearPortStatusArray; 

(***********************************,t^^ttt#ttttt^t^tot^^^^ 

PROCEDURE  UpdateLinkStatus (VAR  StatusArray  : Node St at us Array; 

SpawningNode  : INTEGER; 
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SpawningPort 

TargetNoda 

TargetPort 

LinkStatus 


PortNamaTypa; 
INTEGER; 
PortNamaTypa; 
Status Type) ; 


VAR  SpawningNodeNumber  : INTEGER; 
TargatNodeNumber  INTEGER; 


BEGIN 


Spawn ingNodeNumber 
TargatNodeNumber 


FindNodeNumber  ( Spawn  ingNode) ; 

FindNodeNumber  (TargetNoda) ; 


WITH  sta tusArr ay  [ SpawningNodeNumber]  .PortStatus  [SpawningPort] 


DO 


IF  LinkStatus  - Active  THEN 


Status  :■  Active; 
Direction  :*  Outboard; 


ELSE 


Status  :■  LinkStatus; 


END; 

END; 

WITH  StatusArray [TargetNodeNumber] .PortStatus [TargetPort]  DO 

IF  LinkStatus  - Active  THEN 

Status  Active; 

Direction  :•  Inboard; 

ELSE 

Status  LinkStatus; 


END; 


END; 


END  UpdateLinkStatus ; 

„,„*****t.****^****.*************************“*****) 

PROCEDURE  SetNodeStatusFailed (VAR  StatusArray  : NodaStatusArray; 

NatworkConnactions  : NodeArrayType, 


VAR  NodeNumber  1 INTEGER; 

AdjacentNodeNumber  : INTEGER; 

Port Index  : PortNamaTypa ; 

AdjacantPort  s PortNamaTypa; 


BEGIN 

NodeNumber  :•  FindNodaNumbar (Fai la dNode) ; 


(*  Sat  status  of  node  to  failed.  *) 

StatusArray [NodeNumber] . Status  :■  Failed, 


(*  Sat  status  of  ports  on  this  nods  to  failed  and  the 
ports  on  any  adjacent  node  to  failed.  ) 

FOR  Portlndex  1 TO  NumberOfPortsPerNode  DO 


StatusArray [NodeNumber] .PortStatus [Portlndex] .Status 


Failed; 


WITH  NetvorkConnections [NodeNumber] .PortArray [Portlndex]  DO 


CASE  AdjacentElement  OF 


GPC,  DIU,  Non®: 

I Node: 

AdjacentNodeNumber  FindNodeNumber (Node Address ) • 

AdjacentPort  :«  Port; 

StatusArray [AdjacentNodeNumber] -PortStatus 
[AdjacentPort]  .Status  .--Failed; 


END; 


END; 


END; 


END  SetNodeStatusFailed; 

(*  This  procedura  takes  an  array  of  type  PortStatusArray  and 
converts  it  to  a PortEnableRegister.  If  an  element  in  the 
PortStatusArray  is  Active  then  the  corresponding  element  in 
the  PortEnableRegister  is  set  to  Enabled,  otherwise  the 
element  is  sat  to  Disabled.  *) 

PROCEDURE  ConvertPortStatusToEnable (VAR  PortStatus  : PortStatusArray; 

VAR  EnableRegister  : PortEnableRegistarType) ; 

VAR  Port Index  : PortNameType; 

BEGIN 


FOR  Portlndex  :■  1 TO  NumberOfPortsPerNode  DO 
IF  PortStatus [Portlndex] .Status  - Active  THEN 
EnableRegister [Portlndex]  :«  Enabled; 


ELSE 


EnableRegister [Portlndex]  Disabled; 


END; 


END; 


END  ConvertPortStatusToEnable; 


(* 

(* 


**************************  ********* 
This  procedure  will  initialize  the 
needs  to  maintain  the  network.  *) 


********************************+tj 

variables  that  the  network  manager 


PROCEDURE  Initial! zeStatus Variables (NodeConnections  : NodeArrayType; 

VAR  NodaStatus  : NodeStatusArray; 

VAR  ChannelStatus  : ChannelStatusRecord) ; 

VAR  Node Index  : INTEGER; 

Channellndex  : Channel IDType; 

Portlndex  : PortNameType; 


BEGIN 

FOR  Nodeindex  1 TO  NumberOfNodes  DO 
WITH  NodeStatus [Nodeindex]  DO 

Address  NodeConnections [Nodeindex] .NodeAddress; 

Status  Idle; 

ClearPortStatusArray (PortStatus } ; 


END; 


END; 
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Channel  Statu  s . GPCAddress 
ChannelStatus . Channel ID 
ChannelStatus . Status 


- 100; 

- A; 

» Idle; 


END  InitializeStatusVariables; 

,***********t*.***************‘**************“**********‘*************) 

(*  This  procedure  computes  how  many  nodas  are  in  the  currant  simulation 
based  on  the  NodeAddress  for  each  node  being  different  than  the 
NodaN umber  - The  Central  Database  initializes  its  network  description 
so  that  each  node  number  is  the  same  as  the  node  address.  If 
this  strategy  is  not  continued  in  the  future,  this  routine  may 

need  to  be  changed.  * ) _ . 

PROCEDURE  Nodes InTh is Simulation (NodeConnections  : NodeArrayType) 

• TWTEGER; 


VAR  NodeCount  : INTEGER; 
Node Index  INTEGER; 


BEGIN 

NodeCount  0; 

FOR  Nodeindex  *.«  1 TO  NumberOfNodes  DO 

IF  Nodeindex  <>  INTEGER (NodeConnections { Nodeindex] .NodeAddress)  THEN 

NodeCount  :«  NodeCount  + 1; 


END; 


END; 

RETURN (NodeCount) ; 

END  Nodes InThis Simulation; 

,**.*****.♦.****. **********************************************************) 
(*  since  the  network  manager  is  the  only  one  to  use  this  routine, 
the  returned  time  will  be  based  on  all  transactions  timing  out 
and  then  adding  one  millisecond  to  account  for  transaction  turn 
around  and  transaction  transmission  time.  *)  _____ 

PROCEDURE  ComputeChainTimeout (NormalCompletions  : INTEGER; 

TimeoutCompletions  : INTEGER)  :REAL; 


VAR  ExecutionTime  : REAL; 

BEGIN 

IF  ((NormalCompletions  + TimeoutCompletions)  MOD  2)  - 0 THEN 

RETURN  (FLOAT (NormalCompletions  + TimeoutCompletions) 

* TransactionTimeOut)  + OneMilliSecond; 


ELSE 


RETURN  (FLOAT (TRUNC ( ( (FLOAT (NormalCompletions 

* TransactionTimeOut)*  + OneMilli Second)  / 

* OneMilliSecond) ; 


+ TimeoutCompletions) 
OneMilliSecond) ) 


END; 

END  ComputeChainTimeout; 


******* ************** t****************************************************' 


( 

END  Utilities. 


GROWNET 


DEFINITION  MODULE  GrowNot; 

FROM  IOSarvica  IMPORT  IORaquaatTyp* ; 

FROM  TypaConst  IMPORT  PortStatusArray,  NodaStatusArray,  NodeArrayTypa, 

FROM  BusMaasag  IMPORT  PortNaaeTypa; 

EXPORT  QUALIFIED  GROWTOROOTNODE,  TranaactionTimeOut , NetworkManagarPriority, 
EXPOKr  DaletaNodaFromNatwork,  AddDIUToNetwork, 

AddGPCToNet^rk^DiaabladTranamitTaat,  DisabladRetransaitTast, 

ResetConfigurationComaand,  MakeMonitorRequast, 

CONST  Transact ionTimeOut  “ 0.000500; 

NetworkManagerP r iority  - 1; 

(.****t***aa**************«*«**««*"*tt#t**t*M******MMM***M****t**) 


PROCEDURE  GROWTOROOTNODE (RootNodaAddress 

RootNoda Inboard?  ort 
NodaStatus 
VAR  IORaquast 


INTEGER; 
PortNaaeTypa? 
NodaStatusArray; 
IORaquastTypa) ; 


,***********—*.**— 


PROCEDURE  EnableLink (SpawningNode 
TargatNoda 
Node Status 

VAR  AddNoda IORaquast 


INTEGER; 

INTEGER; 

NodaStatusArray; 
IORaquastTypa) ; 


(.***.******«*******.******************^**********‘*‘*t**t*****t***t******) 


PROCEDURE  Da leteNodaFromNatwork  ( 

TargatNoda 

Targa  tNodalnboaxdP  ort 
NodaStatus 

VAR  Dale taNoda IORaquast 


INTEGER; 

PortNamaTypa; 

INTEGER; 

PortNaneType; 

NodaStatusArray; 

IORaquastTypa) ; 


(t********^**************************************************1************’ 


PROCEDURE  AddDIUToNetwork  (Node 

Port 

NodaStatus 
VAR  IORaquast 


INTEGER; 
PortNaaeTypa; 
NodaStatusArray; 
IORaquastTypa) ; 


PROCEDURE  AddGPCToNatvorMNoda  ; ™™Typ.; 

NodaStatus  : NodaStatusArray; 

VAR  IORaquast  : IORaquastTypa) ; 

(**..*..*....*.*********»**********^*****<‘*****************************M 

PROCEDOT 

VAR  IORaquast  : IORaquastTypa) ; 

* 

PROCEDURE  Disabl.dR.trai.saitT.stiTMtNod.^  : 

NodaStatus  : NodaStatusArray ; 

VAR  IORaquast  : IORaquastTypa) ; 

(.t.****....******************^******4************************************’ 


PROCEDURE  Reset  Con  f igurationCommand  (TestNode 

NodeS tat 


NodaStatus 
VAR  IORequest 


INTEGER; 

NodaStatusArray ; 
IORaquastTypa) ; 


i*******************************"**************"*************"**********) 

PROCEDURE  MafcaMonitorRequest (NodeConnection  : Nod*ArrayTyp«)  : IORaquastType 

(*****************^**H********n**************H***t****H****H***ttnHJ 

END  GrowN«t . ' 
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GROWNET 


IMPLEMENTATION  MODULE  GrowNet ; 


FROM  IOService  IMPORT  IORequestType,  Request  Ac  tivityType; 

FROM  IOS  IMPORT  ChainType,  TransactionType; 

FROM  CentralDB  IMPORT  FindNodaNumber; 

FROM  TypeConst  IMPORT  NodeStatusArray,  NodaArrayType; 

FROM  BusMessag  IMPORT  PortNameType,  PortEnablaRegisterType, 
BusMassageType,  DIUCommandType,  NumberOfNodes f 
MaJceNodeConf igur at i onCommand , MakaMo  nit orCommand ; 

FROM  Utilitiaa  IMPORT  ConvertPortStatusToEnable,  ComputeChainTimeout; 

FROM  QueuaM  IMPORT  InitQ,  QInsert,  QSize,  dNEW; 

FROM  Storaga  IMPORT  ALLOCATE; 

FROM  SYSTEM  IMPORT  SIZE; 

FROM  InOut  IMPORT  WriteString,  Writelnt,  WriteReal,  WriteLn; 

(**********t ****************  *************  ****************************** j 

PROCEDURE  GROWTOROOTNODE (RootNodaAddraaa  : INTEGER; 

RootNodalnboardPort  : PortNamaTypa; 

NodeStatus  : NodeStatusArray; 

VAR  IORaquast  : IORaquastTypa) ; 

CONST  GrowToRootNode  Identifier  - 305; 

VAR  Transaction  : TransactionType; 

Command  : BusMassageType; - 

PortEnabiaRegister  : P or tEnableRegi star Type; 

RootNumbar  : INTEGER; 


BEGIN 

dNEW (IORaquast, SIZE (IORaquast A) ) ; 

IORequestA,refcnt  :*  0; 

IORaquast A . copycnt  1; 

IORaquastA . naxtq  NIL; 

dNEW ( IORaquast A. Chain, SIZE ( IORequestA .ChainA) ) ; 

IORaquast A.ChainA. ref cnt  0; 

IORaquast A . Chain A . copycnt  : - 1 ; 

IORaquastA. Chain A. naxtq  NIL; 

dNEW (Transaction, S IZE (TransactionA ) ) ; 

Transact ion A .rafcnt  0; 

Transaction A . copycnt  :»  1; 

Transact ion A .naxtq  NIL; 

IORequestA . ChainA . TransactionQueue  InitQ ("TransactionQueue",  FALSE,  0) ; 

RootNumbar  ; * FindNodeNumber (RootNodaAddr ass) ; 

(*  Now  convert  Configuration  into  a Port  Enable  Register  command.  *) 
ConvartPortStatusToEnable (NodaStatus [RootNumbar] .PortStatus,  PortEnablaRegister) ; 

(*  Generate  the  command  to  grow  to  the  Root  Node.  *) 

Command  MakeNodeConfigurationCommand(RootNodeAddress,  PortEnablaRegister); 

(*  Generate  the  transaction.  *) 

WITH  TransactionA  DO 

Identifier  :*  RootNodeAddress; 

TimeOutValua  :=  TransactionTimeOut; 

OutputFrame  : - Command; 


END; 
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(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  IORequestA .Chain A .Transact ionQueue,  FALSE); 

INSERT  Transaction  LAST  IN  IORequestA .Chain* . Trans actionQueue; 


WITH  IOReques tA. Chain A DO 

Chainldentifier  Gr owToRootNode Identifier ; 

NumberOfTransactions  QSize{ IOReques tA .ChainA .Trans actionQueue) ; 


END; 

WITH  IORequestA  DO 

Priority  NetworkManagerPriority; 

OnDemand  :■  FALSE; 

Request Timeout Value  ComputeChainTimeout (0,  ChainA .NumberOf Transactions ) ; 

RequestType  NetworkManagerRequest; 


END; 


END  GROWTOROOTNODE; 

(* t ******* * *********** **************************  ******************* ********} 

PROCEDURE  EnableLink (SpawningNode  : INTEGER; 

TargetNode  INTEGER; 

NodeStatus  : Node Status Array; 

VAR  AddNode IOReques t : IORequestType) ; 

CONST  AddNodaToNetworkChain Identifier  » 306; 

VAR  Transaction  : TransactionType ; 

Command  : BusMessageType; 

PortEnableRegister  : PortEnableRegisterType; 

SpawningNumber  : INTEGER; 

TargetNuznber  : INTEGER; 


BEGIN 

SpawningNumber  FindNodeNumber (SpawningNode) ; 

TargetNumber  FindNodeNumber (TargetNode) ; 

dNEW (AddNode IOReques tf  SIZE (AddNodeIORequestA) ) ; 

AddNodeIORequestA .refcnt  :•  0; 

AddNode I OReque st A .copy cnt  :«  1; 

AddNodeIORequestA . nextq  NIL; 

dNEW (AddNodeIORequestA .Chain, SIZE (AddNodelORequest A . Chain A) ) ; 

AddNode IORequestA .Chain A .refcnt  0; 

AddNode I OReque stA. Chain A .copycnt  1; 

AddNode I ORequestA.Cha in A .nextq  NIL; 

AddNodelORequest A .ChainA .TransactionQueue  InitQ ("TransactionQueue",  FALSE,  0); 

(*  Convert  the  spawning  node's  port  status  to  a Port  Enable  Register.  *) 
ConvertPortStatusToEnable (NodeStatus (SpawningNumber] .PortStatus,  PortEnableRegister) ; 

(*  Generate  command  for  Spawning  node  to  turn  on  outboard  port.  *) 

Command  MakeNodeConfigurationCommand (SpawningNode,  PortEnableRegister); 

dNEW (Transaction, SIZE (TransactionA ) ) ; 

Trans act ion A .refcnt  :»  0; 

Transact ion A .copycnt  1; 

Transaction A . nextq  :*  NIL; 

WITH  TransactionA  DO 

Identifier  SpawningNode; 

TimeOutValue  TransactionTimeOut; 

OutputFrame  : « Command; 


END; 
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(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  AddNodelORequest* .Chain * .TransactionQueue,  FALSE); 

INSERT  Transaction  LAST  IN  AddNodelORequest* .Chain* . Transact ion Queue; 


(*  Generate  a transaction  for  target  node  to  turn  on  its  inboard  port.*) 

(*  Convert  the  target  node's  port  status  to  a Port  Enable  Register.  *) 
ConvertPortStatusToEnable (NodeStatus (TargetNumber] .PortStatus,  PortEnableRegister) 

(*  Generate  command  for  Spawning  node  to  turn  on  outboard  port.  *) 

Command  MakeNodeConfigu ratio nComffland( TargetNode,  PortEnableRegister); 

dNEW (Transaction, SIZE (Transaction*) ) ; 

Transaction* .ref cnt  :«  0; 

Transaction* . copycnt  :=«  1; 

Transaction* .nextq  NIL; 

WITH  Transaction*  DO 

Identifier  TargetNode; 

TimeOutValue  :*  TransactionTimeOut; 

OutputFrame  Command; 


END; 


(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  AddNodelORequest* .Chain* .Transact ionQueue,  FALSE); 

INSERT  Transaction  LAST  IN  AddNodelORequest* .Chain* . Tran section Queue; 


WITH  AddNodelORequest* .Chain*  DO 

Chainldentifier  :■»  AddNodeToNetworkChain Identifier; 

NumberOfTransactions  :*  QSize (AddNodeIORequest*,ChainA.TransactionQueue) ; 


END; 

WITH  AddNodelORequest*  DO 

Priority  :=  NetworkWanagerPriority; 

OnDemand  FALSE; 

RequestTimeoutValue  ComputeChainTiraeout (0,  Chain* .NumberOfTransactions) ; 

RequestType  NetworkManagerRequest; 


END; 


END  EnableLink; 


(********************************* ************************************ t****j 


PROCEDURE  De leteNodeFromNet work (Spawn ingNode 

Spawn ingNodeOutboardPort 
TargetNode 

TargetNode Inboar dPort 
NodeStatus 

VAR  DeleteNodelORequest 


INTEGER; 
PortNameType; 
INTEGER; 
PortNameType; 
NodeStatusArray ; 
IORequestType) ; 


CONST  AddNodeToNetworkChainldentif ier  - 307; 


VAR  Transaction  : TransactionType; 

Command  : BusMessageType; 

PortEnableRegister  : PortEnableRegisterType; 

Spawn in gNumber  : INTEGER; 

TargetNumber  : INTEGER; 


BEGIN 

dNEW (DeleteNodelORequest, SIZE (DeleteNodelORequest*) ) ; 
DeleteNodelORequest  *.  ref  cnt  : *=  0; 


DeleteNodaIORequestA . copycnt  1; 

DeleteNodalORequest A . nextq  NIL;  A|. 

dNEW(DeleteNodeIORequestA .Chain, SIZE (DeleteNodelORequest  .Chain  )), 
DeleteNodeIORequestA . Chain A .ref cnt  0; 

DeleteNodelORequest A . Chain A . copycnt  1; 

DeleteNodeIORaquestA. Chain A. nextq  NIL; 

DeleteNodeIORequestA . Chain A . TransactionQueue  :■  In itQ ("Transact ion Queue",  FALSE,  0) ; 


(*  Generate  a transaction  for  target  node  to  turn  off  its  inboard  port.*) 
TargatNumber  FindNodaNumber (TargetNode) ; 


(*  Convert  the  target  node's  port  status  to  a Port  Enable  Register.  *) 
ConvertPortStatuaToEnable (NodeStatus [TargetNumber] .PortStatus,  PortEnab 


PortEnablaReoister) , 


(*  Generate  command  for  Spawning  node  to  turn  on  outboard  port.  *) 
Command  MakeNodeConf igurationCommand (TargetNode,  PortEnableRegister); 


dNEW (Transaction,  SIZE  ( Transaction A) ) ; 
Transaction A .ref cnt  0; 

Transaction A. copycnt  1; 

Trans act ion A . nextq  :■  NIL; 

WITH  TransactionA  DO 


Identifier  TargetNode; 

TimeOutValue  TransactionTiineOut; 

OutputFrame  :*  Command; 


END; 


{*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  DeleteNodeIORaquestA .ChainA .TransactionQueue,  FALSE) ; 

INSERT  Transaction  LAST  IN  DeleteNodeIORequestA .ChainA . TransactionQueue; 

Spawn ingNumber  : * FindNodaNumber (SpawningNode) ; 

{*  Convert  the  spawning  node's  port  status  to  a Port  Enable  Register.  *) 
ConvertPortStatusToEnable (NodeStatus [Spawn ingNumber] .PortStatus,  PortEnableRegister) 


(*  Generate  command  for  Spawning  node  to  turn  on  outboard  port.  *) 
Command  MakeNodeConfigurationConmand( SpawningNode,  PortEnableRegister); 


dNEW( Transaction, SIZE (TransactionA) ) ; 
Transaction A . ref cnt  :■  0; 

Trans act ion A. copycnt  1; 

Transaction A .nextq  :™  NIL; 

WITH  TransactionA  DO 


Identifier  :*  SpawningNode; 
TimeOutValue  TransactionTimeOut; 
OutputFrame  :*  Command; 


END; 

(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  DeleteNodelORequest*. Chain*. TransactionQueue,  FALSE) ; 

INSERT  Transaction  LAST  IN  DeleteNodelORequest* .Chain* .TransactionQueue; 


WITH  DeleteNodeIORequestA .Chain A DO 


Chainldentifier 
NumberOf Transactions 


: - AddNodeToNe tworkChain Identifier; 

QSize (DeleteNodeIORequestA.ChainA. TransactionQueue) ; 


END; 


WITH  DeleteNodelORequest A DO 


Priority 

OnDemand 


NetworkManagerPriority; 

FALSE; 


RequestTimeout Value  ComputeChainTimeout (G,  Chain A .NumberOf Transact ions) ; 

RequestType  :=»  NetworkManagerRequest; 


END; 

END  DeleteNodeFrcsnNetwork; 

(* t****** ******************* *****t********** ***************************** 

PROCEDURE  AddD IUToNe two rk (Node  : INTEGER; 

Port  : PortNameType; 

NodeStatus  : NodeStatusArray ; 

VAR  IORequest  : IORequestType) ; 


CONST  AddDIUIdantif ler  - 308; 


VAR  Transaction 
Command 

PortEnableRegister 

NodeNumber 


: TransactionType; 

: BusMessageType; 

: PortEnableRegisterType; 
: INTEGER; 


BEGIN 

dNEW( IORequest;  SIZE  (IORequestA) ) ; 

IORequest A .ref cnt  :»  0; 

IORequest A . copycnt  :»  1; 

IORequestA .nextq  NIL; 

dNEW ( IORequest A .Chain, SIZE { IORequest A . Chain A) ) ; 

IORequastA .ChainA . ref cnt  :»  0; 

IORequest A , Chain A . copycnt  1; 

I ORequestA. Chain A .nextq  :«  NIL; 
dNEW  (Transaction,  S I2E  (TransactionA ) ) ; 

Transaction A .ref cnt  0; 

Trans act ion A .copycnt  1; 

Transact ion A .nextq  NIL; 

IORequest A. Chain A.TransactionQueua  InitQ ("Transact ionQueue",  FALSE,  0) ; 

NodeN umber  : « FindNodeNumber (Node) ; 

{*  Now  convert  Configuration  into  a Port  Enable  Register  command.  *) 
ConvertPortStatusToEnable (NodeStatus [NodeNumber j .PortStatus,  PortEnableRegister) ; 

(*  Generate  the  command  to  grow  to  the  Root  Node.  *) 

Command  : - MakeNodeConf igurationCommand (Node,  PortEnableRegister) ; 

{*  Generate  the  transaction.  *) 

WITH  TransactionA  DO 

Identifier  Node; 

TimeOutValue  :*  Tran sac tionTimeOut; 

OutputFrame  : - Command; 


END; 

(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  IORequest A .Chain A .Trans actionQueue,  FALSE); 

, INSERT  Transaction  LAST  IN  IORequestA .ChainA .Trans actionQueue; 

WITH  IORequest A .Chain A DO 

Chainldentifier  :*  AddDIUIdentif ier ; 

NumberOfTransactions  :=  QSize ( IORequestA .ChainA .TransactionQueue) ; 

END; 

WITH  IORequestA  DO 

Priority  : = NetworkManagerPriority; 
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OnDemand  *m  FALSE; 

Request Timeout Value  ;«  ComputeChainTimeout (0,  Chain ".NumberOf Transact ions ) ; 
RequestType  NetworkManagerRequest; 


END; 


END  AddDIUToNetwork; 

(*.****.***********************************“******************************> 

PROCEDURE  AddGPCToNatwork (Nod»  : INTEGER; 

Port  : PortNameType ; 

NodeStatus  : NodeStatusArray; 

VAR  IORequest  : IORequestType) ; 


CONST  AddGPC Identifier  - 309; 


VAR  Transaction 
Command 

‘ PortEnableRegister 
NodeNumber 


Tran sac tionType; 
BusMesaageType; 
PortEnableRegisterType; 
INTEGER; 


BEGIN 


dNEW { IORequest , SIZE ( IORequest A ) ) ; 

IORequestA . ref cat  0; 

IORequest A . copycnt  :*  1; 

IORequest A . nextq  :*  NIL; 

dNEW ( IORequest A .Chain, SIZE (IORequest A . Chain A) ) ; 

IORequestA . ChainA . ref cnt  ;»  0; 

IORequest A .Chain A .copycnt  1; 

IORequest A. Chain A. nextq  NIL; 

dNEW (Transaction, SIZE (TransactionA ) ) ; 

Transaction A .ref cnt  0; 

Transact ion A . copycnt  :*  1; 

Transaction A .nextq  NIL; 

lORaquest* .Chain* . TransactionQuaue  InitQ("TransactionQuaue",  FALSE,  0) ; 


NodeNumber  : - FindNodaNumber (Node) ; 


(*  Now  convert  Configuration  into  a Port  Enable  Register  command.  *) 
ConvertPortStatusToEnable (NodeStatus (NodeNumber) .PortStatus,  PortEnableRegister) ; 


(*  Generate  the  command  to  grow  to  the  Root  Node.  *) 

Command  :«  MakeNodeConf igurationCommand(Node,  PortEnableRegister); 


( * Generate  the  transaction.  *) 
WITH  Transaction A DO 


Identifier  :*  Node; 

TimeOutValue  :«  TransactionTimeOut; 
OutputFrame  :*  Command; 


END; 

(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  IORequest" . Chain" .TransactionQueue,  FALSE); 

INSERT  Transaction  LAST  IN  IORequest" .Chain" .TransactionQueue; 


WITH  IORequest A .Chain A DO 

Chainldentifier  AddGPCIdentif ier ; 

NumberOfTransactions  QSize ( IORequest" .Chain" . TransactionQueue) ; 


END; 

WITH  IORequest"  DO 
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Priority  NetworkManagerPriority; 

OnDemand  FALSE; 

Request Timeout Value  ComputeChainTimeout (0,  Chain A . NumberOfTransactions) ; 

RequestType  NetworkManagerRequest; 


END; 

END  AddGPCToNetwork; 


(******************************  ********t*********o************************ 


PROCEDURE  Di sab ledTransmit Test (Tar getN ode  : INTEGER; 

Node Status  : NodeStatus Array; 
VAR  IORequest  : IORequestType) ; 


CONST  DisabledTransmitldentif ier  - 250; 


VAR  Transaction 
Command 

PortEnableRegister 
Targe tNumber 


Trans act ion Type; 
BusMessageType ; 
PortEnableRegisterType; 
INTEGER; 


BEGIN 

dNEW (IORequest , SIZE  (IORequest A) ) ; 

IORequest A . ref cnt  0; 

IORequest A . cop ycnt  :«  1; 

IORequest A . nextq  NIL; 

dNEW ( IORequest A . Chain,  SIZE  ( IORequest A .ChainA) } ; 

IORequest A . ChainA . ref cnt  0; 

IORequestA , ChainA . copycnt  1; 

IORequest A . Chain A . nextq  : - NIL; 
dNEW (Transaction, SIZE (Transaction^  ) ; 

Trans act ion A . ref cnt  0; 

Trans action A . copycnt  :»  1; 

Transaction A, nextq  NIL; 

IORequestA . ChainA . TransactionQueue  :■=  InitQ ("TransactionQueue",  FALSE,  0)  ; 

Targe tNumber  :*  FindNodeNumber (TargetNode) ; 

(*  Now  convert  Configuration  into  a Port  Enable  Register  command.  *} 
ConvertPortStatusToEnable (NodeStatus [TargetNumber] . PortStatus,  PortEnableRegister) ; 

(*  Generate  the  command  to  disable  all  ports  on  target  node*) 

Command  MakeNodeConf igur at ionCoramand( TargetNode,  PortEnableRegister); 

(*  Generate  the  transaction.  *) 

WITH  Transaction A DO 

Identifier  TargetNode; 

TimeOut Value  : * TransactionTimeOut; 

OutputFrame  Command; 


END; 

(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  IORequest A . Chain A .TransactionQueue,  FALSE); 

INSERT  Transaction  LAST  IN  IORequest A .ChainA .TransactionQueue; 

WITH  IORequest A . Chain A DO 

Chainldentif ier  :=  DisabledTransrait Identifier; 

NumberOfTransactions  : = QSize ( IORequestA .Chain A .TransactionQueue); 


END; 
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WITH  IORequest A DO 
Priority 


:=  NetworkManagerPriority; 


RaquastTimaout Value  ComputeChainTimeout  ( 0 , Chain*. NumbarOfTransactions)  ; 

RequestType  NatworkManagerRe quest; 


END; 


END  DisabladTransmitTast; 

**********************  ********* 


********************************* 


**) 


PROCEDURE 


DisabledRetransmitTest (TestNode 

TargetNode 
NodeStatus 
VAR  IORequest 


INTEGER; 

INTEGER; 

Nodes tatusAr ray; 
IOReques  tType ) ; 


CONST  DisabledRetransmitChainldentif ier  - 251; 

VAR  Transaction  ' TransactionType; 

Command  : BusMessageType; 

portEnabl a Register  ; PortEnablaRagisterTypa; 

Spawn in gNumbar  INTEGER; 

TargetN umber  ’ INTEGER; 


BEGIN 

Spavm ingNumber  FindNodaNumber (TestNode) ; 

TargetNumbar  FindNodaNumbar (Tar gatNode) ; 

dNEW(  IORequest, SIZE (IORaquest A) ) ; 

IORequest A .ref cnt  0; 

IORequest* . copycnt  1; 

IORequest* . nextq  NIL;  A.  . 

dNEW( IORequest* .Chain, SIZE (IORaquest  .Cham  )), 

IORaquas tA . Chain A . ref cnt  0; 

IORaquest A .ChainA . copycnt  1; 

IORaquas tA . Chain A . naxtq  :*  NIL; 

IORequest*  .Chain*  .Transact ionQueue  :»  In itQ ("Transact ionQueue  , FALSE,  0)/ 

Enable  Register.  *) 

.PortStatus,  PortEnableRegistar ) 

(*  Generate  command  for  Spawning  node  to  turn  off  the  port  connected 

Commandh%ttokeNodeConfigurationComiiand(TestNode,  PortEnableRegister) ; 

dNEW (Transaction, SIZE (Transaction  ) ) ; 

Transaction* .refcnt  :«  0; 

Transaction* . copycnt  :«  1; 

Transact ion A . nextq  :*  NIL; 

WITH  Transaction*  DO 

Identifier  TestNode; 

TimeOutValue  : “ TransactionTimeOut; 

OutputFrame  : » Command; 


(*  Convert  the  spawning  node's  port  status  to  a Port 
ConvertPortStatusToEnable  (NodeStatus  ( Spawn  ingNumber] 


END; 

(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  IORequest* .Chain* . Transact xonQueue,  FALSE), 

INSERT  Transaction  LAST  IN  IORequest* .Chain* . Tr ans act ionQueue ; 

(*  Generate  a transaction  for  target  node  to  return  its  status.  *) 

ConvertPortStatusToEnable^  .PortStatus^PortEnableRegister) ; 

<*  Generate  command  for  Spawning  node  to  return  its  status.  *) 

Command  MakeMonitorCommand(TargetNode) ; 


dNEW (Transaction, SIZE (Transaction A) ) ; 
Transaction A. ref cnt  0; 
TransactionA.copycnt  1; 

Transact ion A .nextq  NIL; 

WITH  Transaction A DO 


Identifier  TargetNode; 

TimeOut Value  TransactionTimeOut; 

OutputFrame  :«  Command; 


END; 

(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  I OR equestA .Chain A .TransactionQueue,  FALSE) ; 

INSERT  Transaction  LAST  IN  IORequestA . ChainA .TransactionQueue; 


WITH  IORequest A .Chain A DO 

Chainldentif ier  : * DisabledRetransmitChainldentifier; 

NumberOfTransactions  QSize  {IORequest A . Cham A . TransactionQueue) ; 

END; 

WITH  IORequestA  DO 

Priority  NetworkManagerPriority; 

OnDemand  : - FALSE; 

RequestTimeout Value  :»  ComputeChainTimeout (0,  Chain A .NumberOfTransact ions) • 
RequestType  Ne tworkMan age r Request; 


END; 


END  DisabledRetransmitTest; 


PROCEDURE  Reset  Con  figur  at  ionCommand  (TestNode  : INTEGER; 

NodeStatus  : Nodes tatus Array; 
VAR  IORequest  : lORequestType) ; 

CONST  ResetConf igurationldentif ier  = 252; 


VAR  Transaction  : Trans act ionType; 

Command  : BusMessageType; 

PortEnableRegister  : PortEnableRegisterType; 

TestNumber  ; INTEGER; 


BEGIN 

dNEW  (IORequest,  SIZE  (IORequest A) ) ; 

IORequestA . refcnt  0; 

IORequestA . copycnt  :»  1; 

IORequestA .nextq  NIL; 

dNEW ( IORequest A. Chain, SIZE ( IORequestA .ChainA) } ; 

I ORequestA. Chain A. refcnt  0; 

IORequest A . Chain A . copycnt  : =*  1; 

I OReques tA  . Cham A .nextq  :=  NIL; 
dNEW  (Transaction, SIZE (TransactionA ) ) ; 

Transact ion A. refcnt  0; 

Trans act ion A . copycnt  1; 

Trans act ion A .nextq  NIL; 

IORequestA.ChainA. TransactionQueue  :«  InitQ ( "TransactionQueue”,  FALSE,  0) ; 
TestNumber  :=»  FindNodeNumber (TestNode) ; 

(*  Now  convert  Configuration  into  a Port  Enable  Register  command.  *) 
ConvertPortStatusToEnable (NodeStatus [TestNumber] .PortStatus,  PortEnableRegister) 

(*  Generate  the  command  to  grow  to  the  Root  Node.  *) 
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Command  MaJcaNodaConfigurationCommanddastNode,  Por tEcableRegis t.r ) ; 

(*  Generate  the  transaction.  *) 

WITH  Transaction  DO 

Identifier  TestNode; 

Tima Outvalue  Tran sac tionTimeOut; 

OutputFrame  Command; 


(* 

M 


END; 

{*  Enter  the  transaction  on  the  Transaction  Quaue.  *) 

QInsart (Transaction,  IORaquast* .Chain* .TransactionQuaua,  FALSE), 

INSERT  Transaction  LAST  IN  IORaquast". Chain*. TransactionQuaua; 


WITH  IORequestA. Chain A DO 


Chainldantifier 
NumberOf Transactions 


RasetConfiguration Identifier; 

QSize ( IORequest A . Chain A .TransactionQuaua) ; 


END; 


WITH  IORequast A DO 

Priority 

OnDemand 

Request Timeout Value 
RequestType 


NetworkManagerPr ior i ty ; 

FALSE;  . 

ComputaChainT imeout ( 0 , Chain". NunbarOfTransactions) ; 

NetworkManagerReques  t ; 


END; 


END  ResetConfigurationCommand; 


>*******************************************) 


(***t ******************** ******** 

PROCEDURE  Mak^IonitorRaquest  (NodeConnection  : NodeArrayType)  : iORequestType, 

CONST  TalkerOutOfTurnldentifier  - 253; 


VAR  MonitorRequest  : IORequestType; 

Transaction  ; TransactionTypa; 

Command  : BusMassageType; 

Node Index  : INTEGER; 


BEGIN 


dNEW {MonitorRequest, SIZE (MonitorRequest A } ) ; 
MonitorRequest A . ref cnt  0; 

MonitorRequest A .copycnt  1; 

MonitorRequest A.nextq  :»  NIL;  ... 

dNEW (MonitorRequest A. Chain,  SIZE (MonitorRequest  .Chain 
MonitorRequest A .ChainA .ref cnt  0; 

MonitorRequest A .Chain A .copycnt  :*  1? 

MonitorRequest A . Chain A . next q :•  NIL; 

MonitorRequest A.ChainA. TransactionQuaua 

FOR  Nodelndex  :=  1 TO  NumberOfNodes  DO 


)); 


InitQ ("TransactionQueue” , FALSE,  0); 


WITH  NodeConnection (Nodelndex]  DO 

f*  A node  addresses  are  initialize  to  their  index  in  the 
array,  if  the  address  is  not  the  index  than  a node 
must  be  present  in  this  index.  *) 

IF  NodeAddress  <>  Nodelndex  THEN 

Command  :«  MakeMoni tor Command (NodeAddress ) ; 

dNEW (Transaction, SIZE (Transaction^ ) ; 

Transaction A .ref cnt  0; 

TransactionA . copycnt  :■  1; 
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Transaction* .nextq  NIL; 
WITH  Transaction*  DO 


Identifier  NodeAddress; 
TimeOutValue  TransactionTimeOut; 
Ou tputFrame  :*  Command; 


END; 

QInsert (Transaction,  MonitorRequest* .Chain* .TransactionOueue,  FALSE) ; 

END; 


END; 


END; 

WITH  MonitorRequest* .Chain*  DO 

Chainldentifier  TalkerOutOfTurnldentifier; 

NumberOfTransactions  :=  QSize  (MonitorRequest* . Chain* . TransactionQueue) 

END; 


WITH  MonitorRequest*  DO 

Priority  :»  NetworkManagerPriority; 

RaquastTiaeoutValue  ComputeChainTimeout {0,  Chain* .NumbarOfTransactions) ; 
unDemand  ' :=*  FALSE; 

RequestType  :«  NetworkManagerRequest; 

END; 


RETURN  (MonitorRequest) ; 

END  MakeMonitorRequest ; 

(*n*****H***H**********H********H****** 

END  GrowNet. 


********************  ***********) 


B-102 


REPAIR 


DEFINITION  MODULE  Repair; 


FROM  lOService  IMPORT  IORequestType; 

FROM  IOS  IMPORT  Chains tatusData; 

FROM  TypeConst  IMPORT  NodeAr ray Type,  Node Status Array,  Channel IDType; 
FROM  BusMessag  IMPORT  PortNameType,  Number Of Nodes; 

EXPORT  QUALIFIED  NodaSetRange,  NodeSet,  Analysis Status Type,  FaultType, 
Fau ItAnaly s isRecordType , ErrorRecordType,  BranchArrayType, 
ReconnectRoot,  Br an chRe connect,  TalkToRootOfTree, 

Er r or Analysis ; 

TYPE  NodaSetRange  - [1  ..  NumberOfNodes j ; 

NodeSet  - SET  OF  NodaSetRange; 

BranchArrayType  - ARRAY  [1  ..  3]  OF  NodeSet; 

AnalysisStatusType  - (AnalysisSucessful,  AnalysisUnsucessful) ; 
FaultType  - (Root Lin kFai lure,  LinkFailure) ; 

FaultAnalysisRecordType  « RECORD 

CASE  Fault  : FaultType  OF 

RootLinkFailure : 

FailedChannel  : ChannellDType; 

I LinkFailure : 

FailedRoot  : INTEGER; 

FailedlnboardPort  : PortNameType; 

FailedNodeSet  : NodeSet; 

FailedNodeCount  : INTEGER; 


END; 


END; 

ErrorRecordType  =*  RECORD 

CASE  Status  ; AnalysisStatusType  OF 
AnalysisSucessful : 

Fau ItAnalysisRe cord  ; FaultAnalysisRecordType; 
I AnalysisUnsucessful: 

END; 


END; 


(***************************  ****** 


**************************************** ^ 


PROCEDURE  ReconnectRoot (NodeConnections  : NodeArrayType; 

VAR  NetworkStatus  : NodeS tat us Array ; 

TargetNode  ; INTEGER; 

FailedNodeSet  : NodeSet; 

VAR  ReconnectlOReqeust  : IORequestType; 

VAR  PortCount  : INTEGER) 

: BOOLEAN; 


******************** ***********) 


PROCEDURE  BranchReconnect (ErrorReport 

NodeConnections 
VAR  ReconnectNode 


ErrorRecordType ; 
NodeArrayType ; 
INTEGER; 
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VAR  ReconnectPort  : PortNameType; 

VAR  Node Status  : Node Status Array; 

VAR  Branches  : BranchArrayType; 

VAR  BranchReconnectlORequest  : IORequestType ; 

VAR  Port Count  : INTEGER) ; 


f**************.***********************************************************1 


PROCEDURE  ErrorAnalysis (MonitorResponse 

NetworkConfiguration 
NodeConnections 
VAR  ErrorReport 
VAR  PortCount 


Chains tatusDat a; 
NodeStatusArray; 
NodeArrayType; 
ErrorRecordType ; 
INTEGER) } 


z^************************************************************************’ 


PROCEDURE  TalkToRootOf Tree (Root 

VAR  TalklORequest 


INTEGER; 
IORequestType) ; 


(*****n*****H*H*H*H****tn*Ht**iH****H** 


********** ************ *****) 


END  Repair. 
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REPAIR 


IMPLEMENTATION  MODULE  Repair; 


FROM 


TvpeConst  IMPORT  NodeArrayType,  NodeStatus Array,  PortStatusArray, 
StatusType,  PortConf igurationType,  NetworkElementType, 
ChannellDType; 


FROM  BusMessag  IMPORT  PortNameType,  BusMessageType , 

PortEnableRegisterType,  NumberOfPortsPerNode,  NumberOfNodes, 
MakeNodeConf igurationComaand,  MakeMonit or Command; 

FROM  IOService  IMPORT  IORequestType,  RequestActivityType; 

FROM  IOS  IMPORT  ChainType,  Transact ionType,  ChamStatusData, 

InputFrameType,  InputFrameQu.ueType,  TimeOut IndicatorType; 


FROM  CentralDB  IMPORT  FindNodeNumber; 

FROM  GrowNet  IMPORT  Transact ionTimeOut,  NetworkManagerPriority; 

FROM  Utilities  IMPORT  ConvertPortStatusToEnable,  ComputeChainTimeout ; 
FROM  QueueM  IMPORT  QInsert,  InitQ,  FirstQ,  QSucc,  QSiza,  dNEW; 


FROM  Storage  IMPORT  ALLOCATE; 


FROM  SYSTEM  IMPORT  SIZE; 

FROM  InOut  IMPORT  WriteString,  WriteLn; 


CONST  ReconnectChainldentif ier  - 221; 

TalkChain Identifier  - 222; 

(****^***t*******t**t*****t****t*^*tt**o*^^***tt^^************^,***) 

PROCEDURE  GetNodeReaponse  (Responses  : InputFrameQueueType, 

Node  : INTEGER; 

VAR  NodeResponse  : InputFrameType) ; 

VAR  InputFrame  : InputFrame Type; 

BEGIN 

NodeResponse  :■  NIL; 

InputFrame  FirstQ (Responses) ; 

LOOP 

IF  FindNodeNumber  (InputFrame*  .MessageAddr ess)  * Node  THEN 

NodeResponse  :*  InputFrane; 

EXIT; 


END; 


InputFrame  QSucc (InputFrame,  Responses); 
IF  InputFrame  - NIL  THEN 

EXIT; 


END; 


END; 


END  GetNodeResponse; 

i*,******.*****.************************************”*********************' 

(*  This  procedure  saarchs  the  network  status  for  an  idle  port  on  this 
node  that  is  connected  to  another  node. 

If  so,  the  port  and  a true  value  will  be  returned,  otherwise  false 
will  be  returned.  *} 


PROCEDURE  IdlePortOnNode (TestNode 

NetworkStatus 
NetworkConnections 
VAR  IdlePort 
VAR  Count 


INTEGER; 

NodeStatusArray ; 
NodaArrayTypa ; 
PortNameType; 
INTEGER)  : BOOLEAN; 


VAR  IdlaPortFound  : BOOLEAN ; 
TestNumber  : INTEGER; 


BEGIN 

TestNumber  FindNodaNumber {TestNode} ; 
LOOP 


INC (Count) ; 

IF  (Nat work Statu a [TestNumbar] . PortStatus [IdlaPort] .Status  - Idle) 
AND  (NatworkConnections [TestNumbar] . PortArray [ IdlaPort] . 

Ad jacentE lenient  - Node)  THEN 

IdlaPortFound  :*=  TRUE; 

EXIT; 

ELSIF  (IdlaPort  - NumberOfPortsPerNode)  THEN 

IdlaPortFound  FALSE; 

EXIT; 


ELSE 


IdlaPort  :=  IdlePort  + 1; 


END; 


END; 


RETURN (IdlaPortFound) ; 
END  IdlePortOnNode; 


(*  This  procedure  checks  tha  Spawning  node  to  saa  if  it  is  present  in 
the  failed  node  set . If  it  is  not#  the  true  will  be  returned  with 
tha  spawning  port,  otherwise  false  will  be  returned,  *) 


PROCEDURE  ValidSpawningNode (SpawningNode 

TargetNode 
NetworkStatus 
NetworkConnections 
FailedNodeSet 
VAR  SpawningPort 
VAR  Count 


INTEGER; 

INTEGER; 

NodeStatusArray; 
NodeAr r ayType ; 
NodeSet; 
PortNameType; 
INTEGER)  : BOOLEAN; 


VAR  ValidSpawningNodeFound  : BOOLEAN; 
SpawningNumber  : INTEGER; 


BEGIN 

SpawningNumber  : - Fin dNodeNumber (SpawningNode) ; 

(*  Check  to  see  if  spawning  node  is  in  failed  node  list.  *) 

IF  NodeSetRange (SpawningNumber)  IN  FailedNodeSet  THEN 

(*  Spawning  Node  was  in  failed  node  set.  A valid  spawning  node 
has  NOT  been  found.  *) 

ValidSpawningNodeFound  :»  FALSE; 


ELSE 


(*  Determine  outboard  port  of  spawning  node  *) 
SpawningPort  :*  1; 

LOOP 
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INC (Count) ; 

IF  SpawningPort  m NumberOfPortsPerNode  THEN 

ValidSpawningNodeFound  :•  FALSE; 

EXIT; 

ELSIF  NetworkStatus [SpawningNumber] .PortStatus [SpawningPort] . 
Status  O Idle  THEN 

SpawningPort  :«  SpawningPort  + 1; 

ELSIF  (NetworkStatus (SpawningNumber]  .PortStatus 
(SpawningPort] .Status  - Idle)  AND 
(NetworkConnections [SpawningNumber] .PortArray 
[SpawningPort] .NodeAddress  <>  TargetNode)  THEN 

SpawningPort  SpawningPort  + 1; 


ELSE 


ValidSpawningNodeFound  TRUE; 
EXIT; 


KHOj- 


END; 


END; 

RETURN  (ValidSpawningNodeFound) ; 


END  ValidSpawningNode; 

,********.************^***********’‘*******************t****************t**) 
(*  This  procedure  formats  an  I/O  chain  for  the  Network  manager  to 

reconnect  a spawing  node  to  a target  node . * ) 

PROCEDURE  MakeReconnactChain(SpawningNoda 

SpawningPort 
TargetNode 
TargetPort 
NetworkStatus 
VAR  Re con nectRe quest 


INTEGER; 
PortNameType ; 
INTEGER; 
PortNameType; 
NodeStatus Array; 
IORequestType) ; 


VAR  SpawningNumber 
TargetNumber 
Transaction 
Command 

PortEnableRegister 


INTEGER; 

INTEGER; 

TransactionType ; 
BusMessageType ; 
PortEnableRegister Type ; 


BEGIN 


SpawningNumber  :»  FindNodeNumber  (SpawningNode)  ; 

TargetNumber  :«  FindNodeNumber  (TargetNode)  ; 
dNEW (Reconnect Request , SIZE (ReconnectRequest  )) , 

ReconnectRequest A . ref cnt  0; 

ReconnectRequest A . copycnt  1; 

ReconnectRequest A.nextq  NIL;  , 

dNEW (ReconnectRequest A .Chain, SIZE (ReconnectRequest  .Cham  )), 

ReconnectRequest A . ChainA .ref cnt  :■  0; 

Recon nectRe quest A . ChainA . copycnt  1; 

ReconnectRequest A .Chain A .nextq  NIL; 

ReconnectRequest A .Chain A . Transact ionQueue  InitQCTransactionQueue",  FALSE,  0) 


(*  Convart  the  spawning  node's  port  status  to  a Port  Enable  Register . *) 
ConvartPortStatusToEnabla (NetworkStatus [SpawningNumber] .PortStatus, 
PortEnableRegister) ; 


(*  Generate 
Command  : - 


:ommand  for  Spawning  node  to  turn  on  outboard  port.  *) 

ikeNodeConfigurationCommand( SpawningNode,  PortEnableRegister) , 


dNEW (Transaction, SIZE (TransactionA ) ) ; 
Transaction^ .refcnt  :«  0; 

Transaction A . copycnt  :«  1; 

Transaction A .nextq  : - NIL; 

WITH  TransactionA  DO 

Identifier  SpavmingNode; 

TimeOutValue  :=■  Tran  sac  tionTimeOut; 
OutputFrame  Command; 


END; 

(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  ReconnectRequest A .ChainA . TransactionQueue,  FALSE) ; 

INSERT  Transaction  LAST  IN  ReconnectRequest A .Chain A .TransactionQueue; 

(*  Generate  a transaction  for  target  node  to  turn  on  its  inboard  port.*) 
( Convert  the  target  node's  port  status  to  a Port  Enable  Register.  *) 
ConvertPortStatusToEnable (NetworkStatus [TargetNumber] .PortStatus 
PortEnableRegister) ; ' 

(*  Generate  command  for  Spawning  node  to  turn  on  outboard  port.  *) 
Command  MakeNodeConf igurationCommand (Targe tNode,  PortEnableRegister) ; 

dNEW (Transaction, SIZE (Transaction A) ) ; 

Transaction^  refcnt  0; 

Transaction A .copycnt  1; 

Transaction A .nextq  NIL; 

WITH  TransactionA  DO 

Identifier  :*  TargetNode; 

TimeOutValue  : - TransactionTimeOut; 

OutputFrame  :»  Command; 

END; 

(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsert (Transaction,  ReconnectRequest A . Chain A . TransactionQueue,  FALSE) ; 

INSERT  Transaction  LAST  IN  ReconnectReqeust A . ChainA . TransactionQueue; 


WITH  ReconnectRequest A .Chain A DO 

Chainldentifier  ReconnectChainldentif ier; 

NumberOf Trans action 3 QSize (ReconnectRequest" .Chain' .TransactionQueue) ; 

END; 


WITH  ReconnectRequest A DO 


Priority 

OnDemand 

Request Timeout Value 
RequestType 


NetworkManagerPriority; 

FALSE; 

ComputaChainTimaout (0,  Chain* . NumbarOfTransactions) 
NetworkManagerReques  t ; 


END; 


END  MakeReconnectChain ; 


PROCEDURE  FindBranches  (FailedNodeSet 
FailedRoot 
NodeConnections 
Node Status 

VAR  BranchesFromRoot 

VAR  Node Index  : INTEGER; 

Port Index  : PortNameType ; 


NodeSet; 

INTEGER; 
NodeArrayType; 
Node Status Array; 
BranchArrayType) ; 


B-110 


Branchlndex  : INTEGER; 
FailedRootNumber  : INTEGER; 
FailedSet  : NodeSet; 


(.********t*.**.***«***************************^******t****************> 


PROCEDURE  TraverseBranch (VAR  BranchSet 

VAR  FailedSet 
FailedRoot 
NodeConnections 
NodeStatus 


NodeSet ; 

NodeSet; 

INTEGER; 
NodeArrayType; 
NodeStatus Array) ; 


VAR  Port Index  : PortNameType; 

FailedRootNumber  : INTEGER; 


BEGIN 

FailedRootNumber  FindNodeNumber (FailedRoot) ; 

FOR  Portlndex  1 TO  NumberOfPortsPerNode  DO 

(♦Determine  the  Number  of  Branches.  Find  the  Root  of  each 
branch  and  put  in  Branch  from  Root  Array.  *) 

WITH  NodeConnections [FailedRootNumber] .PortArray [Portlndex]  DO 

IF  (NodeStatus [FailedRootNumber] .PortStatus [Portlndex] .Status 
- Active)  AND  (AdjacentElement  - Node)  AND 
(Node Set Range (NodeNumber)  IN  FailedSet)  THEN 

(*  A root  of  a branch  has  been  found.  *) 

INCL  (BranchSet,  Node SetRange (NodeNumber) ) ; 

EXCL  (FailedSet,  Node SetRange (NodeNumber) ) ; 

TraverseBranch (BranchSet,  FailedSet,  NodeAddress, 
NodeConnections,  NodeStatus); 


END; 


END; 


END; 


END  TraverseBranch; 


^ ***************** 


***************** 


BEGIN 

(*  Copy  Failed  Node  Set  in  Failed  Set  for  local  manipulation.  ‘) 
FailedSet  :•  NodeSet  { }; 

FailedSet  FailedSet  + FailedNodeSet; 

FailedRootNumber  FindNodeNumber (FailedRoot) ; 

/*  Remove  Failed  Root  from  failed  set.  The  failed  root 
is  from  where  the  branches  start,  so  it  should  not  be 
in  the  failed  node  set.  *) 

EXCL  (FailedSet,  N ode Set Range (FailedRootNumber) ) ; 

(*  Initialize  Branches  from  Root  Of  Failed  Tree  to  Nil.  *) 

FOR  Bran chi ndex  :«  1 TO  3 DO 

BranchesFromRoot [Branchlndex]  NodeSet  { }; 


END; 

Branchlndex  1; 

{♦Determine  the  Number  of  Branches.  Find  the  Root  of  each 
branch  and  put  in  Branch  from  Root  Array.  M 
FOR  Portlndex  :*  1 TO  NumberOfPortsPerNode  DO 


WITH  NodeConnections (Fa iledRootNumber ] .PortArray[ Port Index]  DO 

IF  (NodeStatus [FailedRootNumber] .PortStatus [Port Index] .Status 
- Active)  AND  (AdjacentEleanent  - Node)  AND 
(NodeSetRange(NodaNumber)  IN  FailedNodeSet)  THEN 

{*  A root  of  a branch  has  been  found.  *) 

INCL  (BranchesFromRoot [Branchlndex] , NodeSetRange (NodeNumber) 
EXCL  (FaiiedSet,  NodeSetRange (NodeNumber) ) ; 


Travers eBranch (BranchesFromRoot [Branchlndex] f FaiiedSet, 
NodeAddress,  NodeConnections,  NodeStatus); 

Branchlndex  :«  Branchlndex  + 1; 


END; 


END; 


END; 

END  FindBranches; 

(*o****o*******************ot****************t*****t********************) 

PROCEDURE  ErrorAnalysis {MonitorResponse  : ChainStatusData; 

NetworkConfiguration  : Node Status Array; 

NodeConnections  : NodeArrayType; 

VAR  ErrorReport  : ErrorRecordType; 

VAR  PortCount  : INTEGER) ; 

VAR  NodeResponse  : InputFrameType; 

FailedRoot Number  : INTEGER; 

Node Index  : INTEGER; 

Port  Index  : PortNaraeType; 


BEGIN 

PortCount  0; 

ErrorReport . Status  :**  AnalysisSucessful; 

IF  MonitorResponse * .AllFailed  THEN 

WITH  ErrorReport .FaultAnalysisRecord  DO 

Fault  RootLinkFailura; 

FailedChannel  :*  C; 


END; 


ELSE 

WITH  ErrorReport .FaultAnalysisRecord  DO 

Fault  :«  LinkFailure; 

FailedNodeCount  :=  0; 

FailedNodeSet  :*  NodeSet  {); 

END; 

FOREACH  NodeResponse  IN  Mon itorResponse A . InputFrameOueue  DO 

NodeResponse  :*  Firs tQ (MonitorResponseA . InputFrameOueue) ■ 

LOOP 

IF  NodeResponseA . Transaction! iraeOut Indicator  » TimedOut  THEN 

WITH  ErrorReport. FaultAnalysisRecord  DO 

FailedNodeCount  :»  FailedNodeCount  + 1; 

INCL (FailedNodeSet , FindNodeNumber 
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(NodeResponseA  .MessageAddress) ) ; 


END; 


END; 


NodaRasponse 


QSucc (NodaRasponse, 

Monit  or  Response  A . InputFrameQueue)  ; 


IF  NodaRasponse  “NIL  THEN 
EXIT; 


END; 


END; 

{*  Find  the  inboard  port  of  the  failed  tree.  *) 

WITH  ErrorReport .FaultAnalysisRecord  DO 


IP  FailedNodeSet  - NodaSet  {}  THEN 


(*  Must  have*  been,  a DID  link  failure.  Set  analysis  to 
unsuccessful.  *) 

ErrorReport. Status  :«  AnalysisUnsucessful; 


ELSIF  Root OfFailedTree (FailedNodeSet, 
NodeConnections,  MonitorResponse; 


Networ kConf igurat ion  , 
FailedRoot,  PortCount)  THEN 


FailedRootNumber  : - FindNodaNumber (FailedRoot) ; 


WHILE  (NetworkConfiguration (FailedRootNumber] .PortStatus 

[Port Index] .Status  O Active)  OR 

{NetworkConfiguration [FailedRootNumber] .PortStatus 
[Portlndex] .Direction  <>  Inboard)  OR 

(NodeConnections [FailedRootNumber] .PortAr ray [Portlndex] . 
Adjacent Element  O Node)  DO 

INC (PortCount) ; 

Portlndex  Portlndex  + 1; 


END; 


FailedlnboardPort  Portlndex; 


ELSE 

WriteString ("Unable  to  find  root  of  failed  tree.  ); 
WriteLn {) ; 


END; 


END; 


END; 


END  Error Analysis; 

(****,**...*.*****************“**********‘********************************) 

PROCEDURE  RootOfFailedTree (FailedSet 

NetworkConf igurat ion 
NetworkConnections 
MonitorRespons  es 
VAR  Root 
VAR  Count 
: BOOLEAN; 


NodeSet ; 

NodeStatusArray; 

NodeArrayType; 

ChainStatusData; 

INTEGER; 

INTEGER) 


VAR  FoundRoot 
FailedNodes 
RootNumber 


BOOLEAN; 

NodeSet; 

INTEGER; 


AdjacentNode  : INTEGER; 

Setlndex  : NodeSetRange; 

Index  : PortNamaTypa; 

InboardPort  : PortNamaTypa; 

AdjacentNodaRasponsa  : InputFrameType; 

BEGIN 

FoundRoot  :»  FALSE; 

FailadNodas  :«  FalladSet; 

FOR  Setlndax  1 TO  Number OfNo das  DO 

IF  Satlndex  IN  FailadNodas  THEN 

EXCL (FailadNodas , Satlndex) ; 

(*  Find  tha  inboard  port  of  this  node.  *) 
Portlndex  :■  1; 

LOOP 


INC (Count) ; 

WITH  NetworkConf iguration  [Satlndex]  .PortStatua  (Portlndex]  DO 

IF  (Status  * Active)  AND  (Direction  ™ Inboard)  AND 

(NetworkConnactions [Setlndex]  .PortArr ay  [Port Index]  . 
AdjacentElement  - Node)  THEN 

InboardPort  :«  Portlndex; 

EXIT; 


ELSE 


( No  check  is  make  for  last  port  on  node  because 
we  expect  to  find  an  inboard  port.  *) 
Portlndex  :«  Portlndex  + 1; 


END; 


END; 


END; 

CASE  NatworkConnections [Setlndex] .PortArray[ InboardPort] . 
AdjacentElement  OF 

Noda: 

AdjacentNode  :»  NetworkConnactions [Setlndax] . 

PortArray[ InboardPort] .NodeNumber; 

GetNodeResponse (MonitorResponsasA . InputFrameQueue, 
AdjacentNode,  Ad jacentNodeResponse) ; 

(*  This  loop  will  need  to  modified  to  support 
a failed  node  set  that  does  not  have  a 
root.  *) 

IF  Ad jacentNodeResponse A . Transact ionTimeOut Indicator 
- NormalCompletion  THEN 

FoundRoot  :«  TRUE; 

Root  NetworkConnactions [Setlndex] .NodeAddress ; 

END; 


END; 


END; 


END; 

RETURN  (FoundRoot) ; 
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END  RootOfFailedTree; 


(****.*.*.*..**.****************‘*******“***‘*t“**********t***“*********) 


PROCEDURE  ReconnectRoot (NodeConnections 

VAR  NetworkStatus 

TargetNoda 

FailadNodaSat 

VAR  ReconnectlORequast 

VAR  PortCount 

: BOOLEAN; 


NodeArrayType; 
NodeStatusAr ray ; 
INTEGER; 

NodeSat; 

IORequestType; 

INTEGER) 


VAR  ReconnectSuccessful  : BOOLEAN; 

SpawningNode  • INTEGER; 

SpawningNumbar  : INTEGER; 

Spawn ingPort  ‘ PortNameType; 

TargatPort  : PortNameType; 

TargetNumber  : INTEGER; 

BEGIN 

TargaSJumbar  s - F IndNodaNumbar (TargatNoda) ; 

ReconnectSuccessful  :■  FALSE; 

(*  Sat  Target  Port  to  start  searching  with  port  I.  *) 
TargatPort  :■  1; 

LOOP 


INC (PortCount) ; 

IF  IdlaPortOnNoda  (TargatNoda,  NetworkStatus, 
TargatPort,  PortCount)  THEN 


NodaConnactions , 


/*  A potential  spawing  node  has  bean  identified.  * ) 
SpawningNoda  : - NodaConnactions [TargetNuaber] .PortArray 
* [TargatPort] .NodoAddress; 

SpawningNumbar  ;•  FindNodaNumber  (Spawn ingNode); 


(* 

IF 


"hack  for  a valid  spawning  node.  *) 

/al idSpawn ingNode (Spawn ingNoda , TargatNoda,  NatworkStatus, 
NodaConnactions,  *rWodaSet.  SoawnmqPort f PortCo\j 


(*  Upadate  status  of  the  new  link  used  to  reconnect 

WITH°NatworkStatus [SpawningNumbar] .PortStatus [ Spawn mgPort] 


Status  :*  Active; 
Direction  : * Outboard; 


END; 

VfITH  NetworkStatus  [TargetNumber]  .PortStatus  [TargetPort]  DO 

Status  Active; 

Direction  :w  Inboard; 


END; 

(*  Make  chain  to  reconnect  spawning  node  to  target  node . 

MakaRaconnectChain (SpawningNode,  SpawningPort,  TargetNode 

TargetPort,  NetworkStatus,  Reconnect IORequest ) , 

Reconnect Successful  :*  TRUE; 

EXIT; 


END; 

ELSIF  TargetPort  < NumberOfPortsPerNode  THEN 
TargetPort  :=  TargetPort  + 1; 

ELSE 


THEN 


DO 
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END; 


Reconnect Successful  FALSE; 

EXIT; 


END; 


RETURN (ReconnectSuccessful} ; 
END  ReconnectRoot; 


(******t*  ****************  *********************** 


* ** ****** ** ** * * * ******* * *** j 


PROCEDURE  BranchRe connect (ErrorReport 

NodeConnections 
VAR  Reconnected© 

VAR  ReconnectPort 
VAR  NodeStatus 
VAR  Branches 

VAR  BranchReconnectlORequest 
VAR  PortCount 


ErrorRecordType ; 
NodeArrayType ; 
INTEGER; 
PortNameType; 
NodeStatus Array; 
BranchArrayType ; 
IORequestType; 
INTEGER) ; 


VAR  BranchNode 
Bran chN umber 
SpawningNode 
Spawn in gPort 
F ailedRoot  Number 
Spa  wn  in  gNumbe  r 
ReconnectNumber 


: NodeSetRange; 
: INTEGER; 

: INTEGER; 

: PortNameType; 
: INTEGER; 

: INTEGER; 

: INTEGER; 


{ ***************** ***************************** 

(*  This  function  will  return  a node  from  the  branch.  If  assumes 
that  a branch  with  no  nodes  will  be  passed  to  it.  *) 

PROCEDURE  GetNodeFromBranch (VAR  Branch  ; NodeSet)  : NodeSetRange; 

VAR  Node  : NodeSetRange; 

BEGIN 

Node;-  1; 

LOOP 


IF  Node  IN  Branch  THEN 

EXCL(Branch,  Node); 
EXIT; 


ELSE 


Node  :*  Node  + 1; 

END; 

END; 


RETURN  (Node); 

END  GetNodeFromBranch; 

(*****************t**n*n***n*********n**n**HH****n***** 


***  **** 


*) 


BEGIN 


WITH  ErrorReport . FaultAnalysisRecord  DO 

FxndBranches  (FailedNodeSet,  FailedRoot,  NodeConnections, 
NodeStatus,  Branches); 

FailedRoot  Number  ;=  FmdNodeNumber  (FailedRoot)  ; 
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END; 

BranchNumber  :■  1; 


LOOP 

(*  Check  current  branch  to  see  if  it  has  any  nodes  left  to  check.  *) 
IF  Branches  l BranchNumber]  <>  NodeSet  { } THEN 


(*  Get  a node  from  the  branch.  *) 


BranchNode 
Reconn ectNode 
ReconnectNumber 


TO  luw  ui  . i 

- GetNodeFromBranch  (Branches  [BranchNumber] ) ; 
NodeConnections [BranchNode] .NodeAddress; 
FindNodeNumber  (ReconnectNode)  ; 


(*  Check  this  node  to  see  if  it  contains  any  idle  ports 
which  are  not  connected  to  the  failed  node  set.  ) 

IF  IdlePortOnNode (ReconnectNode,  NodeStatus,  NodeConnections, 
ReconnectPort,  PortCount)  THEN 


(*  A potential  spawing  node  has  been  identified.  ) 
SpawningNode  NodeConnections [BranchNode] .PortArray 

[ReconnectPort] .NodeAddress; 
SpawningNumber  FindNodeNumber  (SpawningNode) ; 

(*  Check  for  a valid  spawning  node.  *) 

WITH  ErrorReport .FaultAnalysisRecord  DO 


IF  ValidSpawningNode ( SpawningNode,  ReconnectNode, 
NodeStatus,  NodeConnections f FailedNodeSet, 
Spawning? ort,  PortCount)  THEN 

(*  upadate  status  of  the  new  link  used  to  reconnect 
nodes.  *) 

WITH  NodeStatus [ Spawn ingNumber ] .PortStatus [ 
SpawningPort]  DO 

Status  :■  Active; 

Direction  Outboard; 


END; 

WITH  NodeStatus [ReconnectNumber ] .PortStatus [ 
ReconnectPort]  DO 

Status  Active; 

Direction  :»  Inboard; 


END; 

(*  Make  chain  to  reconnect  spawning  node  to  target 

node  * ) . 

Make Reconnect Chain (SpawningNode,  SpawningPort, 
ReconnectNode,  ReconnectPort,  NodeStatus, 
BranchReconnectlORequest) ; 

(*  A Node  on  a branch  has  been  identified  for 
attempted  reconnection  to  the  network.  *) 

EXIT; 


END; 


END; 


ELSE 

(*  Loop  again  and  check  for  next  node  in  branch.  *) 


END; 
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ELSE 


BranchNumber  :*  BranchNumber  + 1; 


END; 


END; 

END  BranchReconnect ; 

PROCEDURE  TalkToRootOfTree  (Root  . INTEGER; 

VAR  TalklORequest  : I ©Request Type) ; 

VAR  Transaction  : TransactionType; 

Command  : BusMessageType; 


BEGIN 


dNEW(TalkIORequest , SIZE  (TalkIORequestA) ) ; 
TalkIORequestA .ref cnt  0; 

TalkI0Reque9tA . copyent  1; 

Tal)cI0Requa9tA  .nextq  NIL; 

dNEH (TalklORaquast A . Chain, SIZE (TalklORaquest A 

TalkIORequestA .Chain A .ref cnt  :«  0; 
TaUcIORequestA . Chain A .copyent  :•  1; 
Tal)cIORequestA  .Chain A .nextq  ;«  NIL; 


. Chain A) ) ; 


TalklORaquast A . Chain* . Tr ansactionQuaue  InitQ("TransactionQuaue",  FALSE,  0) 

Command  MaJcaMonitorCommand(Root)  ; 

dNEW (Transaction, SIZE (TransactionA ) ) ; 

Transaction A . ref cnt  :*  0; 

Transaction A . copyent  :«  1; 

Transact ion A . nextq  NIL; 

WITH  Transact ion A DO 


Identifier  Root; 

TiaeOut Value  Tran 3 act ion TimeOut ; 

OutputFrame  Command; 


END; 

(*  Enter  the  transaction  on  the  Transaction  Queue.  *) 

QInsart (Transaction,  TalkIORequest\ Chain'. TransactionQueua,  FALSE); 

INSERT  Transaction  LAST  IN  TalklORaquast*. Charn^.TransactionQuaua; 

WITH  TalkIORequestA .Chain A DO 

Chainldantifier  TalkChainldentifiar; 

NunberOf Transact ions  : = QSiza (TalklORaquast* .Chain* . TransactionQuaua) ; 

END; 


WITH  TalklORequest A DO 


Priority 

OnDemand 

Request Timeout Value 
Request Type 


NetworkManagerPriority; 

* FALSE; 

= ComputeChainTimeout (0,  ChainA 
“ NetworkManagerRequest; 


.NumberOf Trans act ions) ; 


END; 


END  TalkToRootOfTree; 

(ft********************** 


END  Repair . 
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NETM  ANGER 


B-119 


DEFINITION  DEVM  NatManger; 


EXPORT  SpavningNodeType*,  Spawn  ingQuauaType; 

TYPE  Spawn  mgNo  da  Type  - ENTITY 
Noda  : INTEGER; 

END; 

SpawningQuaueType  - QUEUE  OF  SpawningNodaTypa; 
END  NatManger. 
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NETMANGER 
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DEVM  NetManger; 


FRCM  IOService  REACH  IORequestType*, 

IOResponseType  * , 

NetvorkManagerServiceRequest* , 

NewNet works tat eType  * ; 

FRCM  IOS  REACH  ChainStatusData* , ChainType*, 

InputFrameType*,  TransactionType*; 

FRCM  Processor  REACH  Process ingUnit*; 

FRCM  BusMessag  REACH  BusMessageType*; 

FROM  IOService  IMPORT  NetworkManagerActivityType,  NetworkHealthType, 
ChamExecutedWithoutError,  ReleaseChainResponseMemory; 

FROM  IOS  IMPORT  TimeOutlndicatorType; 

FROM  CentralDB  IMPORT  ReadNode  I interconnections,  FindNodeNumber; 

FRCM  TypeConst  IMPORT  NodeArrayType,  NodeStatusArray,  ChannelStatusRecord, 

Net wor kE lament Type , PortStatusArray,  StatusType, 

PortConfigurationType; 

FROM  BusMessag  IMPORT  PortNameType,  NumberOfPortsPerNode, 

NumberOfNodes , MakeMon  it  or  Command; 

FROM  Utilities  IMPORT  InitializeStatus Variables,  Nodes InThis Simulation, 
UpdateLinkStatus,  SetNodeStatusFailed; 

FROM  GrowNet  IMPORT  GROWT OROOTN ODE , EnablaLink,  DeleteNodeFroaNetwork, 

AddDIUToNetwork,  AddGPCToNetwork,  DisabledTransmitTest, 
DisabledRetransmitTest,  ResetConfigurationCommand, 

MakeMon it or Request ; 

FROM  Repair  IMPORT  NodeSetRange,  NodeSet,  FaultType, 

FaultAnalysisRecordType,  ErrorRecordType,  BranchArrayType, 

Err or Analysis,  AnalysisStatusType,  ReconnectRoot, 

BranchReconnect,  TalkToRootOfTree; 

FROM  Senddata  IMPORT  DataE lament Type,  FrequencyType,  NonCyclicDataType, 
NonCyclicVariationType,  WriteDataElementType; 

INPUTS 

EVENT  ServiceRequest  : NetworkManagerServiceRequest; 

IONetworkResponse  : ChainStatusData; 

ProcessorResponse  : ProcessingUnit; 

MissedDeadLine  : INTEGER;  (*  ignored,  since  turned  off  for  the  IOP  *) 

Sasat-  . DAATPur.  ' 


PARA  NetworkIDToManage 
Process ingPriority 
IOPIdentifier 
InitialNodeConf iguration 
InitialOrientation 

END; 


INTEGER; 

INTEGER; 

INTEGER; 

ARRAY  (1  ..  NumberOfNodes] , fl 
ARRAY  [1  ..  NumberOfNodes],  [1 


NumberOfPortsPerNode]  OF  BOOLEAN; 
NumberOfPortsPerNode]  OF  BOOLEAN; 


OUTPUTS 

VAR  IONetworkRequest  : IORequestType; 

NewNetworkState  : NewNetworkStateType; 
ProcessorRequest  : ProcessingUnit; 


END; 


TYPE  NatworkManagerJobType  - (GROWNetwork,  RepairNetwork) ; 

GrowNatworkModaType  - (GrowToRootNode,  AddRamainingNodes , AddDIUS, 
AddGPCS,  DiagnosticCheck) ; 

RepairNetworkModeType  = (DisconnectLink,  RepairLink,  ReconnectLink, 

ReconnectBranch,  TalkToRootFailedTree) ; 
DiagnosticModeType  = (LinkEnable,  DisabledTransmit,  DisabledRetransmit , 
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Reset Configuration,  TalkerOutOfTurn, 
DiagnosticaComplete) ; 

DIUSpawningRecord  - ENTITY 

SpawningNode  : INTEGER; 

OutboardPort  : PortNameType; 


END; 

GPCSpawningRacord  - ENTITY 

SpawningNode  : INTEGER; 
Inboar dPort  : PortNameType; 


END; 


DIUListQueueType  - QUEUE  OF  DIUSpawningRecord; 
GPCListQueueType  * QUEUE  OF  GPCSpawningRacord; 

DiagnoaticRecordType  - RECORD 

Diagnostic  : DiagnosticModeType; 

TestNode  INTEGER; 

TestPort  : PortNameType; 

TargetNode  • INTEGER; 

TargetPort  s PortNameType; 

LinkEnableSucessful  : BOOLEAN; 
PortDiagnoaticsRun  : BOOLEAN; 

Talker Request  : IORequestType; 


END; 

NetworkGrowthProgresaType  “ RECORD 

CASE  Mode  : GrowNetworkModeType  OF 

GrowToRootNode : 

RootNodeAddress  : INTEGER; 
InboardPort  : PortNameType; 

| AddRamamingNodes ; 

SpawningNode  : INTEGER; 
SpawningPort  : PortNameType; 
TargetNode  : INTEGER; 
TargetPort  : PortNameType; 

| AddDIUS: 

DIUAddress  : INTEGER; 

| AddGPCS : 

SpareRootNodeAddress  : INTEGER; 

1 DiagnosticCheck : 


END; 


END; 


Process ingType  - (Powerup,  GrowRequest,  NetworkRequest, 
NewState,  FaultAnalysis) ; 

ProcessType  * RECORD 

CASE  Message  : Process ingType  OF 


Powerup: 


I GrowRequest,  NetvorkRequest,  Fault Analysis  : 
lORaquest  : IORequestTypa; 
i NewState  : 


StateData  : NewNetworkStateTypa; 


END; 


END; 

DataPointer  - POINTER  TO  ProcessType; 

CONST  NetworkManagerPriority  * 1; 

NodaPowerupInitilizeTime  - 0.000025 
GrowInitializeNodeTime  - 0.000025 
NatworkResponseComputation  - 0.000050 
ComputeOneTransactionChain  - 0.000075' 
Compu teTwoTr ansae tionChain  - 0.000150, 


ChangeNetworkStatus 
FixadErrorReport Analysis 
PortError Analysis 

VAR  Networks tat a 

RequastForService 

NodaConn act ions 

NodaStatus 

ChannelStatus 

Spawn ingQueue 

DIUList 

GPCList 

NatworkManagar Status 

NatworkGrowthPrograss 

DiagnosticStatus 

Nodes InNatwork 
NumbarOf Act ivaNode s 

NatworkRasponsa 

RepairNetworkMode 

ErrorReport 

BranchNoda 

BranchPort 

Bran chesOf Root 

ReconfigurationStrategy 

AnalysisPortDecisions 

DataCollact ionRecord 

Nodal ndex 

Port Index 

Error Index 

Transaction 

SourcaNoda 

Targe tNode 

PreviousChainFailed 

GoodRootNodaFound 

P ower upRaqu a s t 

NatworkRasponsaRaquest 

ProcessRasponsa 

PowarupProcessing 

NatworkRasponsaPro cessing 

Process ingRasponse 

Las tN e t wor kRequ a s t 

RootNoda 

FailedNode 

CurrantPort 

IOPPort 


* 0.000025; 

- 0.000075; 

* 0.000005; 

: NewNetworkStateTypa; 

: NetworkManagerServiceRequest 

: NodeArrayType; 

: NodaStatusArray; 

: ChannelStatusRecord; 

: SpawningQuaueType; 

: DIUListQueueType; 

: GPCListQueueType; 

: NetworkManagerJobTypa; 

: NatworkGrowthPrograssTypa; 

: DiagnosticRecordType; 

: INTEGER;  * 

: INTEGER; 

• ChainStatusData; 

• RapairNetworkModaTypa; 

: ErrorRecordType; 

: INTEGER; 

: P or  tNameType ; 

: BranchArrayType; 

: RapairNetworkModaTypa; 

: INTEGER; 

: Dat aE lament Type; 

: INTEGER; 

: PortNameType; 

: INTEGER; 

: TransactionType; 

: INTEGER; 

: INTEGER; 

: BOOLEAN; 

: BOOLEAN; 

: DataPointer; 

: DataPointer; 

: DataPointer; 

: ProcessingUnit; 

: ProcessingUnit; 

: ProcessingUnit; 

: IORequestTypa; 

: INTEGER; 

: INTEGER; 

: Por tNameType; 

: INTEGER; 
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(***************t*<Hk************************o*****************************) 

(*  This  procedure  uses  a Node  Status  Array  and  a Network  Connection 
Array  to  determine  if  a Spawning  Noda  has  any  ports  to  which 
an  idle  node  is  connected.  When  an  idle  node  is  found,  the 
search  is  stop,  the  Idle  Node  Variable  is  set,  and  the  BOOLEAN 
return  variable  is  set  to  TRUE,  the  First  Port  to  Check  variable 
is  set  to  the  next  port  to  check  on  the  next  call  to  this  routine. 

Any  ports  connected  to  DIU'  s found  during  this  search  are  entered 
on  a DIU  list  for  later  use.  If  no  ports  connected  to  idle 
ports  are  found,  then  the  BOOLEAN  is  set  to  FALSE.  *) 

PROCEDURE  FoundAdjacentldleNode  (SpawningNode 

VAR  Spawn ingNodeOutboardPort 
VAR  IdleNode 

VAR  TargetNodalnboardPort 
NodeConnections 
NodeStatus 
DIUList 
GPCList 


INTEGER; 
PortNameType; 
INTEGER; 
PortNameType; 
NodaArr ayType ; 
NodeStatusArray ; 
DIUListQueueType ; 
GPCListQueueType ) 


VAR  Port Index 

FoundldleNode 

DIURecord 

GPCRecord 

Spawni n gNodeNumber 

I dleNodeNumber 


BEGIN 


: BOOLEAN; 

PortNameType; 

BOOLEAN; 

DIUSpawningRecord; 

GPCSpawningRecord; 

INTEGER; 

INTEGER; 


FoundldleNode  ;■  FALSE; 

Spawn  in  gNodeNumber  : - FindNodeNumber  (SpawningNode) ; 


LOOP 


CASE  NodeConnections [SpawningNodeNumber]  . 

PortArray  [SpawningNodeOutboardPort]  . AdjacentElement  OF 

Node: 

IF  {NodeStatus [NodeConnections [SpawningNodeNumber] . 

PortArray [SpawningNodeOutboardPort] .NodeNumber] . 

Status  - Idle)  AND  (NodeStatus [SpawningNodeNumber] . 

PortStatus[ SpawningNodeOutboardPort] .Status  - Idle)  THEN 

IdleNode  NodeConnections [SpawningNodeNumber] .PortArray 

[ Spawn ingNodeOutboardPort ] . NodeAddres  s ; 

I dleNodeNumber  NodeConnections [SpawningNodeNumber] .PortArray 

( SpawningNodeOutboardPort ] . NodeNumber ; 
FoundldleNode  :«  TRUE; 

Port  Index  :**  1; 

LOOP 


WITH  NodeConnections  [I dleNodeNumber]  .PortArray  [Portlndex]  DO 


CASE  AdjacentElement  OF 
Node : 

IF  NodeAddres s - SpawningNode  THEN 

TargetNodalnboardPort  :*  Portlndex; 
EXIT; 


ELSE 


Portlndex  Portlndex  + 1; 


END; 


ELSE 
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Portlndex  Portlndex  + 1;  ' 


END; 


END; 


END; 


END; 

| DIU: 

NEW  (DIURecord) ; 

DIURecord* .Spawn ingNode  SpawningNode; 

DIURecord* . Ou  thoardPort  :»  Spawn  mgNodeOu  thoardPort ; 

INSERT  DIURecord  LAST  IN  DIUList; 

! GPC : 

(*  This  check  keeps  the  root  link  currently  used 
for  growth  from  being  put  on  the  GPCList.  *) 

IF  NodeStatus [Spawn ingNodeNumber ] .PortStatus { Spa wningNodeOu thoardPort] 
Status  - Idle  THEN 

NEW (GPCRecord) ; 

GPCRecord* . SpawningNode  SpawningNode; 

GPCRecord* . InboardPort  :«  SpawningNodeOutboardPort; 

INSERT  GPCRecord  LAST  IN  GPCList; 


END; 


ELSE 


END; 

IF  FoundldleNode  THEN 
EXIT; 

ELSIF  Spawn ingNodeOu tboardP or t < NumberOfPortsPerNode  THEN 
SpawningNodeOutboardPort  :«  SpawningNodeOutboardPort  + 1; 

ELSE 


EXIT; 


END; 


END; 

RETURN  (FoundldleNode); 

END  FoundAdjacentldleNode; 

(* *************  ****************  ************************************** *******j 

PROCEDURE  NaxtNodeToAdd ( VAR  GrowthStatus  : NetworkGrowthProgreasType; 

NodeConnections  : NodeArrayType; 

VAR  NodeStatus  : NodeStatus Array; 

DIUList  : DIUListQueueType) ; 

VAR  Next Spawn  ingNode  : SpawningNodeType; 

NodeToAddToNetwork  : SpawningNodeType; 

DIUElement  ; DIUSpawningRecord; 

AddRemainingNodesIORequest  : IORequestType; 

AddDIUIORequest  : IORequestType; 

RequestToAddNode  : DataPointer; 
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P rocess ingToAddNode  : Process ingUnit; 

RequestToAddDIU  : DataPointer; 

ProcessingToAddDIU  : Process ingUn it; 

Nod® Index  : INTEGER; 


BEGIN 

(*  Find  out  if  all  the  porta  on  the  apawning  nod®  have  been  checked, 
if  not  continue  from  the  current  apawning  node, 
otherwise  get  a new  apawning  node.  *) 

LOOP 


WITH  GrowthStatus  DO 

IF  FoundAd jacentldleNode (SpawningNode,  SpawningPort,  TargetNode, 

TargetPort,  NodeConnections,  NodeStatus,  DIULiat,  GPCList)  THEN 

(*Add  the  idle  node  to  spawning  queue.  *) 

NEW  (NodeToAddToNetwork) ; 

NodeToAddToNetworkA .Node  TargetNode; 

INSERT  NodeToAddToNetwork  LAST  IN  Spawn i n gQueue  ; 

(*  Update  Status  of  the  two  nodes  that  are  being  used  to 
add  the  next  node.  *) 

UpdateStatusLinkEnable (SpawningNode,  SpawningPort,  TargetNode, 

TargetPort , NodeStatus ) ; 

EnableLink (SpawningNode,  TargetNode,  NodeStatus,  AddRemainingNodesIORequest); 

AddRemainingNodesIORequest* . Chain A .NetworkToBeExecutedOn  Network IDToManage 

AddRemainingNodesIORequest*. Identifier  :*  MyNodelD; 

AddRemainingNodesIORequeatA . ResponseExpected  :*  TRUE; 

NEW (RequestToAddNode) ; 

RequestToAddNodeA. Message  NetworkRequeat; 

RequestToAddNode A.IORequeat  AddRemainingNodesIORequest; 

NEW (Process ingToAddNode) ; 

Process ingToAddNodeA. Priority  NetworkManagerPnonty; 

Process ingToAddNode A .ProceasingRequired  : - ComputeTwoTransactionChain 

+ NetworkResponseComputation; 

Process ingToAddNode A . WriteData  *“  FALSE, 

ProcessingToAddNodeA .ProcessID  'NW  Add  Node  Processing  ; 

Process ingToAddNode A .Data  RequestToAddNode; 

NOW  outport [ IOPPort] A .ProcessorRequest  O Process ingToAddNode; 

EXIT; 

ELSIF  QSize (Spawn in gQueue)  - 0 THEN 

FOR  Nodeindex  1 TO  NumberOfNodes  DO 

IF  NodeStatus (Node Index] .Status  - Idle  THEN 
NodeStatus [Node Index] .Status  :■  Failed; 


END; 


END; 


(★  Set  mode  to  add  DIUs.  *); 

Mode  AddDIUS; 

(*  All  good  nodes  are  a part  of  the  network,  now  start 
adding  dius . *) 

DIUElement  ; - FirstQ(DIUList ) ; 

REMOVE  DIUElement  FROM  DIUList; 

{*  Update  spawning  node  and  spawning  port  status  so 
network  manager  will  know  what  status  to  change.  *) 
WITH  DIUElement A DO 


NodeStatus [FindNodeNumber (Spawn ingNode) ] .PortStatua 
[OutboardPort] .Status  Active; 

NodeStatus [FindNodeNumber (Spawn ingNode) J .PortStatua 
[OutboardPort] .Direction  :«  Outboard; 

AddDIUToNetwork (SpawningNode,  OutboardPort,  NodaStatus, 
AddDIUIORequest) ; 

(*  Data  Collection.  *) 

DIUAddrass  : - NodeConnections [FindNodaNumbar { Spawn ingNoda) ] . 
PortAr ray [OutboardPort] .DIUAddraaa; 


END; 


DISPOSE (DIUE lament) ; 

AddDIUIORequest A .Chain A .NetworkToBeExecutedOn 
AddDIUIORequest A . Identifier  MyNodalD; 
AddDIUIORequest A .Re sponaeExpec ted  TRUE; 


NetworkIDToManage ; 


NEW  (RequestToAddDIU)  ; 

Request To AddDIUA .Message  NetworkRequest; 

Request To AddDIUA . IORequeat  :«  AddDIUIORequest; 


NEW(ProcessingToAddDIU) ; 
ProcessingToAddDIUA .Priority 
ProcessingToAddDIUA .ProceasingRequired 

Process in gToAddDIUA .ProceasID 
ProcassingToAddDIUA .WriteData 
Proces  singToAddDIUA .Data 


Net workManagerPr ior ity ; 
ComputeOneTransactionChain 
+ NatworkRasponseComputation 
'NW  Add  DIU  Processing'; 

FALSE; 

RequestToAddDIU; 


NOW  outport [ IOPPort ] A . ProcessorRequest  <-  Proces singToAddDIU; 


END; 


REMOVE  FIRST  Next Spawn ingNode  FROM  Spawn in gOueue; 
SpawningNode  NextSpawningNodeA .Node; 
SpawningPort  :»  1; 

DISPOSE (Next Spawn ingNode) ; 


END; 


END; 


END  NextNodaToAdd; 


(*****«**.*, ***********************„  *****»******************************, 
(*  This  procdura  parforms  the  diagnostic  checks  durning  network  growth 
Since  the  current  model  does  not  include  the  failure  modes  that 
this  diagnostic  sequence  checks,  not  attempt  is  made  to  process  the 
responses . It  is  assumed  that  the  chains  produced  by  this  routine 
will  complete  normally.  *) 


PROCEDURE  RunDiagnostic (VAR  DiagnosticStatus  : DiagnosticRecordType; 

VAR  NodeStatus  : NodeStatusArray; 

NodeCon figuration  : NodeArrayType) ; 


) 


VAR  TestNodeNumber 
TargetNodeNumber 
Process ingTime 
Disconnect IORequeat 
DiagnosticRequest 
Diagnosticprocessing 


BEGIN 


INTEGER; 

INTEGER; 

REAL; 

IORequestType; 
DataPointer ; 
ProcessingUnit; 


WITH  DiagnosticStatus  DO 


TestNodeNumber  FindNodeNumber (TestNode) ; 

(*  Determine  if  the  current  test  port  should  run  tests. 
If  so,  start  tests,  otherwise,  determine  if  all  ports 
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reset  configuration  and 


have  been  tested.  If  so,  run 
talker  out  of  turn  test.  *) 

IF  Diagnostic  « LinkEnable  THEN 

(*  Determine  the  next  port  under  test.  *) 

LOOP 

WITH  NodeConfiguration [TestNodeNumber]  .PortArray  [TestPort]  DO 


IF  {AdjacentElement  - Node)  AND 

(NodeStatus  [NodeNumber]  .Status  - Idle)  AND 
{NodeStatus (TestNodeNumber] . Ports tatus 
i>?A«fPnrt  1 . status  - Idle)  THEN 


(*  A Port  with  an  adjacent  idle  node  has  been  found 

TargetNode  NodeConfiguration[TestNodeNumber 1 . 

PortArray [TestPort] .NodeAddress ; 
TargetPort  NodeConfiguration [TestNodeNumber ] . 

PortArray [TestPort] .Port; 


*) 


EXIT; 

ELSIF  TestPort  < NumberOfPortsPerNode  THEN 

TestPort  TestPort  + 1; 

ELSIF  PortDiagnosticsRun  THEN 

(*  No  more  ports  to  test  and  some  idle  ports  have 
been  tested.  *) 

Diagnostic  ResetConfiguration; 

EXIT; 

ELSE 

(.  This  node  has  no  idle  ports  to  run  diagnostics  on, 
no  reason  to  reset  its  configuration.  ) 
Diagnostic  :■  TalkarOutOfTurn; 

EXIT; 


END; 


END; 


END; 


END; 

TargetNodeNumber  NodeConfiguration [TestNodeNumber] . 

y p or t Ar r ay [ Tes  tPo  r t ] . NodeNumbe  r , 


NEW(DiagnosticRequest) ; 
DiagnosticRequest A .Message 

CASE  Diagnostic  OF 


NetworkRequest; 


LinkEnable : 

(*  Update  port  status  so  that  Enable  Link  will  generate 
the  proper  command.  Only  set  status  since  it  will  be 
changed  back  later  in  diagnostics.  *) 

PortDiagnosticsRun  :■  TRUE; 

NodeStatus  [TestNodeNumber]  .PortStatus  l"  ^ Active; 

NodeStatus [TargetNodeNumber] .PortStatus [Targe 

EnabieLink (TestNode,  TargetNode,  NodeStatus,  DiagnosticRequest^ . IGRequest) ; 


DiagnosticRequest^ KEat*  '.ResponseExpected  TRUE; 


NetworkIDToManage 


ProcessingTime 

Diagnostic 

I DisabledTransmit : 


ComputeTwoTransactionChain; 

DisabledTransmit; 


IF  NOT (LinkEnableSucessful)  THEN 


(*  Mark  the  links  failed,  generate  request  to 
disconnect  failed  links,  and  set  diagnostic 
mode  to  link  enable.  *} 

NodeStatus (FindNodeNumber (TestNode ) ] .PortStatus 
[TestPort]  .Status  .--Failed; 

NodeStatus [FindNodeNumber (TargetNode) ] . 

PortStatus [TargetPort] .Status  Failed; 


DeleteNodeFromNetwork (TestNode, TestPort,  TargetNode, 

TargetPort,  NodeStatus,  Diagnost icRequestA . IORequest) ; 

DiagnosticRequestA . IORequest A .Chain"*  .NetworkToBeExecutedOn  : - NetworkIDToManage 
Diagnost lcReouest  . IORemiest A THant-i 


DiagnosticRequest A . IORequest A . Identifier 
D iagn  os  t i cReque  s t A . IORequest A . ResponseExpected 
ProcessingTime 
Diagnostic 


MyNodelD; 

TRUE; 

ComputeTwoTransactionChain ; 
LinkEnable; 


E1SE 


NodeStatus [ Targe tNodeNumber] .PortStatus [TargetPort] .Status  :«  Idle* 
DisabledTransmitTest (TargetNode,  NodeStatus,  DiagnosticRequest A . IORequest) ; 


DiagnosticRequest A 
Diagnost icReques t A 
DiagnosticRequestA 
ProcessingTime 
Diagnostic 


. IORequest " 
, IORequest" 
IORequest" 


. Chain A . NetworkToBeExecutedOn  : - NetworkIDToManage; 
•Identifier  MyNodelD; 

.ResponseExpected  TRUE; 

*"  ComputeOneTransactionChain; 

Di s ab 1 edRe transmit; 


END; 


I DisabledRetransmit : 


NodeStatus [ Tes tNodeNumber ] .PortStatus [TestPort] .Status  :«  Idle; 

DisabledRetransmitTest (TestNode,  TargetNode,  NodeStatus, 

Diagnos ticRequestA. IORequest ) ; 


DiagnosticRequest A . IORequest A .Chain A .NetworkToBeExecutedOn 
DiagnosticRequest"* . IORequest A . Identifier  MyNodelD; 
Diagnost i cRequest A . IORequest A .ResponseExpected  :»  TRUE; 


NetworkIDToManage ; 


ProcessingTime 
Diagnostic 
TestPort 

ResetConf iguration : 


ComputeTwoTr an  sac  t ionChain ; 
LinkEnable; 

- TestPort  + I; 


ResetConf igurationCommand (TestNode,  NodeStatus, 

Diagnost icRequest A . IORequest) ; 

DiagnosticRequest A . IORequest A . Chain A .NetworkToBeExecutedOn 
DiagnosticRequest"* . IORequest A . Identifier  MyNodelD; 

DiagnosticRequest A . IORequest A .ResponseExpected  :*  TRUE; 

ProcessingTime  :*  ComputeOneTransactionChain 


NetworkIDToManage ; 


Diagnostic 
TalkerOutOf Turn : 


TalkerOutOf Turn ; 


u™nn3tlCRSqU6Stri0ReqU6st  MaJceMonitorR«quost (NodeConnections ) ; (* 

WITH  DiagnosticRequest A . IORequest"*  DO 


PRB  *) 


Chain"*  .NetworkToBeExecutedOn  NetworkIDToManage; 

Identifier  :=  MyNodelD; 

ResponseExpected  TRUE* 


END; 
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END; 


Process ingTime 
Diagnostic 


0.0; 

DiagnosticsComplete; 


END; 


NEW (Diagnosticprocessing) ; 
WITH  DiagnosticProcessingA  DO 


Priority 

Process ingRequ ir e d 
Process ID 
WriteData 
Data 


NetworkManagerPriority; 

ProceasingTime  + NetworkRasponseComputation; 
'NM  Diagnostics'; 

FALSE; 

D iagno s t icReque s t ; 


END; 

NOW  outport (IOPPort] A .ProcessorRequest  <-  Diagnosticprocessing; 


END  RunDiagnostic; 

,.««*****. t*************************************************************!**’ 
(*  This  procadura  updates  the  network  status  variables  after  a successful 
branch  reconnect.  It  sets  the  status  of  all  the  active  ports 
of  the  failed  node  set,  except  the  node  through  which  the  reconnect 

PRO^OTEdOpdateNo^StatusBranchReconnect  (ReconnectNode  : INTEGER; 

ReconnectPort 
FailedRoot 
uno  >JA+'Mf%rlrStatus 


PortNameType; 

INTEGER; 

Qf  a t-n  * A r ra  v \ 


VAR  ReconnectNumber 
FailedRootNumber 
SpawningNumber 
Tar getN umber 
Inboar dPort 
NewInboardPort 
Outboar dPort 


INTEGER; 

INTEGER; 

INTEGER; 

INTEGER; 

PortNameType; 

PortNameType; 

PortNameType; 


BEGIN 


ReconnectNumber  : - FindNodeNumber (ReconnectNode) ; 
FailedRootNumber  FindNodeNumber (FailedRoot) ; 


(*  Since  the  repair  was  sucessful,  there  will  be  two  ports  on  the 
Reconnect  node  that  have  the  status  "inboard". 

One  is  due  to  the  reconnection  of  the  branch  is 
connected  to  the  Reconnect  port,  the  other  is  the  inboard 
port  prior  to  the  failure,  this  one  should  now  be  outboard.  ) 
Spawn ingNumber  :«  ReconnectNumber; 


(*  find  the  port  that  must  be  changed  to  outboard.  * ) 
Outboar dPort  1; 

LOOP 


WITH  NetworkStatus (Spawn ingNumber ] .PortStatus (OutboardPort ] DO 


IF  (Status  - Active)  AND  (Direction  - Inboard)  AND 
(OutboardPort  <>  ReconnectPort)  THEN 

(*  The  old  inboard  port  has  been  found.  *) 
EXIT; 


ELSE 


OutboardPort  OutboardPort  + 1; 


END; 

END; 
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END; 


LOOP 


(*  Chang#  Status  of  old  inboard  port  to  outboard.  *) 

NetworkStatus [ SpawningNumbar ] .PortStatus [OutboardPort] .Status 
NetworkStatus [SpawningNumbar] .PortStatus [OutboardPort] .Diraction  :« 

(*  Chang,  the  status  of  the  port  adjacent  to  the  new  outboard  port 
to  inboard.  *) 

WITH  NodaConnections [SpawningNumbar] .PortArray [OutboardPort]  DO 


:■  Activa; 
Outboard; 


NetworkStatus [NodeNumber] .PortStatus  [Port] .Status  Active- 

NetworkStatus [NodeNumber] .PortStatus [Port] .Direction  Inboard; 


IF  NodeNumber  - FailedRootNumber  THEN 


(*  No  more  port  statuses  naad  to 
EXIT; 


be  changed. 


*) 


ELSE 

SpawningNumbar  NodeNumber; 

OutboardPort  1; 

NawInboardPort  r-  Port; 

LOOP 


WITH  NetworkStatus [SpawningNumbar] .PortStatus [ 
OutboardPort]  DO 

IF  (Status  - Active)  AND  (Direction  - Inboard)  AND 
(OutboardPort  <>  NawInboardPort)  THEN 

{*  The  old  inboard  port  has  been  found.  *) 
EXIT;  ' 


ELSE 


OutboardPort  OutboardPort  + 1; 

END; 


END; 


END; 


END; 


END; 


END; 

END  Updat aNodeSt at usBranchRe connect; 


PROCEDURE  Updat eStatusLinkEnable (SpavmingNode 

Spawn ingPort 
TargetNode 
TargetPort 
VAR  NodeStatus 


VAR  Spawn in gNumber  : INTEGER; 
TargetNumber  : INTEGER; 


INTEGER; 
PortNameType; 
INTEGER; 
PortNameType ; 
NodeStatusArray)  ; 


BEGIN 


SpawningNumber  :»  FindNodeNumber (SpawningNode) ; 
TargetNumber  : - FindNodeNumber (TargetNode) ; 


NodeStatus [SpawningNumber] .PortStatus [SpawningPort] .Status 
NodeStatus [SpawningNumber] .PortStatus [SpawningPort] .Directic 


ActiveX- 

Outboard; 
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NodaStatus [ TarqetNumber ] .PortStatus [TargetPort] .Status 
NodaStatus [TargetNumber] .PortStatus [TargetPort] -Direction 


:»  Active; 

: - Inboard; 


END  UpdateStatusLinkEnable; 

*******  t************  ******  ******* 


************************************* 


) 


PROCEDURE 


St artNet work Growth (RootLinkToGrowFrom 
VAR  GrowProgress 
NodeConnections 
VAR  NodeStatus 


: INTEGER; 

: NetworkGrowthP r ogres sType; 
: NodeArrayType; 

: Node Status Array; 


Nodes InThisNetwork  : INTEGER); 


VAR  RootNodeNumber 
Node Index 
Port Index 
GrowIORequest 
P rocess ingTime 
Request ToGrow 
GrowRequestPro cessing 


INTEGER; 

INTEGER; 

PortNameType; 

IORequestType; 

REAL; 

DataPo inter; 
ProcessingUnit; 


BEGIN 

(*  Now  find  the  Root  Node  connected  to  the  active  IOS.  *) 
FOR  Node Index  1 TO  Nodes I nNet work  DO 


FOR  Portlndex  :»  1 TO  NumberOfPortsPerNode  DO 


IF  (NodeConnections [Nodeindex] .PortArr ay [Portlndex] . 
AdjacentElament  - GPC)  AND 

(NodeConnections  [Nodelndex] .Port Array [Portlndex] . 
GPC Address  - RootLinkToGrowFrom)  THEN 


GrowProgress .RootNodeAddress 
RootNodeNumber 
GrowProgress . InboardPort 


NodeConnections [Nodelndex] .NodeAddress; 
FindNodeNunber (GrowProgress .RootNodeAddress) 
Portlndex; 


END; 


END; 


END; 

WITH  GrowProgress  DO 

*{*^Sat  status°of  Root  Noda  that  is  being  used  for  network  growth.  *)^ 
NodeStatus  [RootNodeNumber]  .PortStatus  [InboardPort]  .Status  . - ^1V®' 

NodaStatus [RootNodeNumber ] . PortStatus [ InboardPort ] -Direction  Inboard, 

GROWTOROOTNODE (RootNodeAddress,  InboardPort,  NodaStatus,  GrowIORequest); 


END; 


GrowIORequest* .Chain* .NetworkToBeExecutedOn 
GrowIORequestA . Identifier 
Growl ORequest* .ResponseExpected 


- Network  IDT oManage; 

- MyNodelD; 

- TRUE; 


i*  This  is  the  processing  time  required  to  execute  this  procedure. 
PrccessinoTime  FLOAT (NodesInThisNetwork)  * GrowImtializeNodeTu 


NEW  (RequestToGrow)  ; 

RequestToGrowA .Message  :*  GrowRequest; 
RequestToGrowA . IORequest  GrowIORequest; 


NEW(GrowRequestProcessing) ; 

GrowRequestProcessingA .Priority 

GrowRequestProcess ingA .ProcessingRequired 
GrowRequestProcessmgA  .WriteData 
GrowRequestProcess ingA .ProcessID 
GrowRequestProcess ingA .Data 


NetworkManagerPriority; 

ProcessingTime; 

FALSE; 

'NW  Grow  Processing'; 
RequestToGrow; 


NOW  outport [IOPPort] * .ProcessorRequest  <-  GrowR&questProcassing; 
END  StartNetworkGrowth; 


{******************  *************** 


**************** ************** *********** 


PROCEDURE  NetworkRepair  (FaultDetectionData  : ChainStatusData; 

VAR  NodeStatus  ; NodeStatusArray; 

NodeConnections  : NodaAr ray Type; 

VAR  ErrorReport  : ErrorRecordType; 

VAR  RepairMode  : RapairNetworkModeType) ; 


VAR  Spawn  ingNode  » INTEGER; 

SpawningPort  : PortNameType; 

Spawn  in  gNodeNumber  : INTEGER; 

Disconnect IORequast  : IORequastType; 

RaquastToDisconnectLink  : DataPointer; 

ProcassingToDisconnectLink  : ProcessingUnit; 

RequastNewStata  ; DataPointer; 

ProcassingNawState  : ProcessingUnit; 


BEGIN 


(*  Analysis  monitor  response  to  determine  the  fault  type,  *) 
ErrorAnalys is (FaultDetectionData,  NodeStatus,  NodeConnections, 
ErrorReport,  AnalysisPortDacisions) ; 

IF  (ErrorReport . Status  « AnalysisSucessful)  AND 

(ErrorReport .FaultAnalysisRecord. Fault  » LinkFailure)  THEN 

REPORT  "%12 . 8f ” clock  TAGGED  "Link  Failure"; 

RapairModa  :*>  DisconnectLink; 


(*  Disconnect  the  failed  tree  from  the  rest  of  the 
network  through  the  broken  noda.  *} 

WITH  ErrorReport. FaultAnalysisRecord  DO 


SpawningNode 


Sp  a wn  i ngNo  deNumb  e r 


SpawningPort 


:*  NodeConnections [FindNodeNumber ( 

FailedRoot ) ] . Port Array [ 
FailedlnboardPort]  .NodaAddress; 
NodeConnections (FindNodeNumber { 

FailedRoot) ] .PortArray[ 
FailedlnboardPort] .NodeNumber; 

: * NodeConnections [FindNodeNumber  ( 
FailedRoot) ] .Port Array! 
FailedlnboardPort] .Port; 


(*  Update  Status  of  the  failed  Links.  *) 

NodeStatus [ SpawningNodeNumber ] .PortStatus( SpawningPort] .Status 
NodeStatus  [FindNodeNumber  (FailedRoot)  ] .PortStatus  [ 
FailedlnboardPort] .Status  :«  Failed; 


Failed; 


END; 


DeleteNodeFromNetwork (SpawningNode, SpawningPort,  FailedRoot, 

FailedlnboardPort,  NodeStatus,  DisconnectlORequest); 


DisconnectlORequest"  .Chain"  .NetworkToBeExecutedOn  : 
Disconnect IORequest" . Chain A . Chainldentif ier  :=  300; 
Disconnect IORequest". Identifier  MyNodelD; 

Disconnect IORequest" .ResponseExpected  :*  TRUE; 


NetworkIDToManage; 


NEW (RaquastToDisconnectLink) ; 

RaquastToDisconnectLink". Message  : = NetworkRequast; 

RequestToDisconnectLink" . IORequest  :=  DisconnectlORequest; 


NEW (ProcessingToDisconnectLink) ; 
ProcassingToDisconnectLink" .Priority 
ProcessingToDisconnectLink" .ProcessingRequired 

ProcessingToDisconnectLink" .WriteData 
ProcessingToDisconnectLink". ProcessID 


NetworkManagerPriority; 
ComputeTwoTransactionChain 
+ NetworkResponseComputation; 
FALSE; 

'Disconnect/Error  Processing'; 
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RequestToDisconnectLink; 


ProcessingToDisconnectLinkA .Data 
NOW  outport [IOPPort] A .ProcessorRequest  <-  ProcessingToDisconnectLink; 

ELSE 


WriteString (ParamOut,  "Don't  know  how  to  repair  this  failure.") 
WriteLn (ParamOut) ; 

WriteString (ParamOut,  "Returning  network  to  service.  ); 

WriteLn (ParamOut) ; 

REPORT  "%12.9fn  clock  TAGGED  "Fault  Analysis  Unsucessful  ; 
REPORT  "%d"  NetworkIDToManage  TAGGED  "ASSUME  DIU  LINK  FAILURE , 


RETURN  TO  SERVICE" 


WITH  NetworkStateA  DO 

NetworkID  s-  NetworkIDToManage; 

State  :*  InService; 

MonitorChain  DiagnosticStatus .TalkerRequestA .Chain; 


END; 

NEW (RequestNewState) ; 

RequestNewStateA. Mas sage  NewState; 

RequestNewStateA . StateData  :«  NetworkStata; 

NEW(ProcessingNewState) ; 

Process ingNewStateA .Priority  NetworkManagerPriority, 

ProcessingNewStateA . Process ingRequired  ChangeNetworkStatus 

+ NetworkResponseComputation; 

ProcessingNewStateA . WriteData  FALSE ; 

ProcessingNewStateA .ProcessID  : “ 'NttW  State  Processing  ; 

Process ingNewStateA .Data  RequestNewState; 

NOW  outport [IOPPort] A .ProcessorRequest  <-  Process ingNewState; 


END; 

END  NetworkRepair; 

(****e********t*****«***tt*o***s***t*****t**t*****t*t********************) 

PROCEDURE  DisconnectLinkProcess (Error_Report  : ErrorRecordType; 

DisconnectResponse  : ChainStatusData; 

VAR  NodeStatus  : Node Status Array ; 

NodeConnections  : NodeArrayType) ; 


VAR  Reconnect I OReque st 

RequestForError Analysis 
Process ingForError Analysis 
ReconnectRootDecisions 
BranchReconnectDecis ions 
IsolationPortDecisions 
ErrorAnalysisTime 


I ORe quest Type; 
DataPointer ; 
Process ingUnit; 
INTEGER; 
INTEGER; 
INTEGER; 

REAL; 


BEGIN 

ReconnectRootDecisions  :*  0; 
BranchReconnectDecisions  :*  0; 


IF  ChainExecutedWithoutError (DisconnectResponse)  THEN 


WriteString (ParamOut  f 
WriteLn (ParamOut) ; 
WriteString (ParamOut , 
WriteLn (ParamOut) ; 
WriteLn (ParamOut) ; 


"Disconnect  Link  chain  executed  without  error.  )/ 
"Something  is  wrong  in  network.  "); 


ELSE 


WITH  ErrorReport .FaultAnalysisRecord  DO 

IF  ReconnectRoot (NodeConnections f NodeStatus,  FailedRoot, 


FailedNodeSet,  ReconnectlORequest, 
ReconnectRootDecisions)  THEN 

RepairNet wor kMode  ReconnectLink; 

Reconf igurationStrategy  ReconnectLink; 

ELS IF  FailedNodeCount  - 1 THEN 


{*  This  situation  should  not  happen  for  the  IAPSA  II 
experiments . *) 

Wri testring {ParamOut,  "Found  a node  which  is  unreachable  ") ■ 
WriteLn  (ParamOut) ; ' ' 

SmSSST'  "°t  “pU“  to 

WriteLn  (ParamOut)  ; 


ELSE 


(*  Reconnect  through  the  branches  of  the  failed  tree  *) 
BranchReconnect (ErrorReport,  NodeConnect ions,  BranchNode, 
BranchPort,  NodeStatus,  B ran c has Of Root , 
Reconnect IOReques t , 
BranchReconnectDecisions ) ;* 

Repair Net wor kMode  :■  ReconnectBranch; 

ReconfigurationStrategy  :«  ReconnectBranch; 


END; 


IsolationPortDecisions  :»  ReconnectRootDecisions  + 

BranchReconnectDecisions ; 

ErrorAnalysisTxme  FixedErrorReportAnalysis  + 

(FLOAT (AnalysisPortDecis ions  + 
IsolationPortDecisions)  * 
PortErrorAnalysis ) 

+ ComputeTwoTransactionChain; 


Reconnect IORequestA . Chain A .NetworkToBeExecutedOn 
ReconnectIORequestA .ChainA .Chain Identifier 
Reconnect IORequestA . Identifier 
Reconnect I OReques t A . Respons  eExpe  cted 


Net wor  k IDT ©Manage ; 
301; 

MyNodelD; 

TRUE; 


NEW (RequestForError Analysis) ; 

RequestForErrorAnalysis  A .Massage  :=  FaultAnalysis- 

RequestForErrorAnalysis  MORequest  ReconnectlORe^uest; 


NEW (ProcessingForErrorAnalysis ) ; 
ProcessingForErrorAnalysis  A .Priority 
ProcessingForErr orAnalysis A. Process ingRequired 

ProcessingForErrorAnalysis  A . Writ eData 
ProcessingForErrorAnalysis A .Process  ID 
Pro ces s ingForErr or Analys is A . Data 


NetworkManagerPriority; 
ErrorAnalysisTime 
+ NetworkResponseComputation; 

FALSE; 

'Link/Branch  Connect  Processing' 
RequestForEr ror Analys is ; 


NOW  outport [IOPPort] A . ProcessorRequest  <-  ProcessingForErrorAnalysis 


END; 


END; 


END  DisconnectLinkProcess; 


PROCPDITBp'd  *******  ****u*****  *****************************  ********t****  *****) 

PROCEDURE  ReconnectLmkProcess  (ErrorReport  : ErrorRecordType; 

ReconnectResponsa  : ChainStatusData) ; 


VAR  TalkToRoot Of FailedTr ee I ORaques  t : IORequestType • 
RequestToTalkToRoot  ; DataPointer  ' 

Process  IngToTallcToRoot  : ProcessingUnit; 


BEGIN 
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IF  ChainExecutedWithoutError(ReconnectResponse)  THEN 

{*  Reconnection  was  sucessful.  Attempt  to  talk  to  root  of 
failed  tree  to  see  if  failed  link  assumption  was  true.  *) 

RepairNetworkMode  !•  TalkToRootFailedTree, 

WITH  ExrorReport .FaultAnalysisRecord  DO 

TalkToRootOfTree (FailedRoot,  TalkToRootOfFailedTreelORequest) ; 


END; 


TalkToRoot OfFa iladTr  as  I ORaquas  t * . Chain*  .NatworkToBaExacutadOn  NetvorkIDToManaga 

. * . ...-.-a  ^ 1 n a r*Vi  a i n T Ha  n t*  i f 1 ar  302; 


TalXIOKOOuuir  ^ ' — * -- 

TalkToRoot OfFailedTree I OReques  t A . ChainA . Chain Identifier 

TalkToRootOf FailedTreelORequest A . Identifier 

TalkToRootOfFailedTreelORequest A . ResponseExpected 


302; 

MyNodelD; 

TRUE; 


NEW ( Reques  tToTalkToRoot ) ; 
RequestToTalkToRootA .Message 
RequestToTalkToRoot A . IORequest 


NetworkRequest; 

TalkToRootOf FailedTree IORequest ; 


NEW (Proces  s ingToTalkToRoot ) ; 

Process ingToTalkToRootA .Priority 

Process ingToTalkToRoot A .Process in gRequired 

ProcessingToTaUcToRootA .WriteData 
Process ingToTalkToRoot A . Proces  sID 
P rocess ingToTalkToRoot A .Data 


NetworkManagerPriority; 

computeOneTransactionChain 

+ NetworkResponseComputation; 

FALSE; 

'NW  Talk  To  Root  Processing'; 
RequestToTalkToRoot; 


NOW  outport [IOPPort] A .ProcessorRequest  <-  Process ingToTalkToRoot; 


ELSE 

WritaStr ing (ParamOut , "Reconnect  Link  encoutered  network  problems."); 
WriteLn (ParamOut) ; 

WriteString (ParamOut,  "Either  NM  logic  error  or  network  problem.  ), 
WriteLn (ParamOut) ; 

WriteLn (ParamOut) ; 


END; 


END  ReconnectLinkProcess; 


PROCEDURE  ReconnectBranchProcess (ErrorReport 

Recon nectResponse 


ErrorRecordType ; 
ChainStatusData) ; 


VAR  TalkToRootOf FailedTree IORequest  t IORequest Type; 
RequestToTalkToRoot  : DataPointer; 

Process  ingToTalkToRoot  : Process ingUmt  ; 


BEGIN 

IF  ChainExecutedWithoutError (ReconnectResponse) THEN 

{*  Branch  reconnect  was  sucessful.  Now  talk  to  the  root 
of  the  failed  tree.  *) 

RepairNetworkMode  :*  TalkToRootFailedTree, 

WITH  ErrorReport . FaultAnalysisRecord  DO 

TalkToRootOfTrae (FailedRoot,  TalkToRootOfFailadTreelORequest) ; 


END; 

TalkToRootOfFailedTreelORequest* .Chain* .NetvorkToBeExecutedOn 

Network IDT oManage ; 

302; 


TalkToRootOfFailedTreeIORequestA .Chain A .Chainldentifier 

TalkToRootOfFailedTr eel OReques tA . Identifier 
TaikToRootOfFailedTreeIORequestA. ResponseExpected 


MyNodelD; 

TRUE; 


NEW ( Reques  tToTalkToRoot ) ; 

RequestToTalkToRootA  Message  NetworkRequest; 

RequestToTalkToRootA . IORequest  TalkToRootOfFailedTreelORequest; 


NEW (ProcessingToTaikToRoot) ; 
ProcessingToTaikToRoot  .Priority 
Process ingToTalkToRoot A .Proces  singRequired 

ProcessingToTaikToRoot . WritaData 
Proces s ingToTalkToRoot .Process  ID 
ProcessingToTaikToRoot A .Data 


NetworkManagerPriority; 

Compu  t e One  Transact ionCh  ain 
+ NetworkResponseComputation 
FALSE; 

'NW  Talk  To  Root  Processing'; 
Reques  t ToTalkToRoot ; 


NOW  outport [IOPPort] A .ProcessorRequest  <-  ProcessingToTaikToRoot; 

ELSE 


Failure  indicates  something  unexpected  happened. 

Either  model  is  not  working  right,  a latent  failure 
is  present,  a second  failure  has  occured,  or  there  is  a 
problem  in  the  network  manager  logic.  *) 

WriteString (ParamOut,  "Repair  action  for  branch  reconnect  unsucessful  ")  • 
WriteLn (ParamOut) ; 1 9 

WriteString (ParamOut,  "SIMULATION  ERROR."); 

WriteLn (ParamOut) ; 


END; 

END  ReconnectBranchProcess ; • 

i************************^***^******^^^**^^*******^**********^) 

PROCEDURE  TalkToRootProcess (Response  : Chains tatusData; 

ReconnectNode  : INTEGER; 

ReconnectPort  : PortNameType) ; 

VAR  Reques tNewState  : DataPointer; 

Process ingNewState  : Proces singUnit; 


BEGIN 


IF  ChainExecutedWithoutError (Response)  THEN 

(*  Successfully  talked  to  root  of  failed  tree  so  link  has  been 
repaired.  If  repair  strategy  was  branch  reconnect,  then 
update  Node  Status  to  reflect  the  new  orientation  of  the  nodes 
in  the  failed  node  3et.  *) 

IF  Reconf igurationStrategy  - ReconnectBranch  THEN 

UpdateNodeStatusBranchReconnect {ReconnectNode,  ReconnectPort, 

ErrorReport .FaultAnalysisRecord .FailedRoot,  NodeStatus) ; 

END; 


WITH  DiagnosticStatus .TalkerRequestA . Chain A DO 

NumberOf Transactions  : - QSize (DiagnosticStatus . TalkerRequest A . ChainA . 

TransactionQueue)  ; 

NetworkToBeExecutedOn  NetworkIDToManage; 


END; 

NEW(NetworkState) ; 

WITH  NetworkStateA  DO 

NetworkID  NetworkIDToManage; 

State  :»  InService; 

MonitorChain  :=  DiagnosticStatus  . TalkerRequest  .Chain; 


END; 
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NEW  (RequestNewState) ; 

RequestNewStateA .Massage  NewState; 

RequastNewStateA . StataData  NetworkState; 


NEW(ProcesaingNewState) ; 

Process ingNewStateA . Priority 

Process ingNewStateA . ProcessingRaquired 

ProcessingNewStateA.WriteData 
ProcessingNewStateA .Process  ID 
ProcessingNewStateA . Data 


NetworkManagerPriority; 

ChangeNetworkStatus 

+ NatworkResponseComputation; 

FALSE; 

'New  State  Processing'; 
RequestNewStata; 


NOW  outport [IOPPort] A .ProcassorRaquast  <-  ProcessingNewState; 


ELSE 

{*  Could  not  talk  to  root  of  failed  traa.  Link  failure 
assumption  wrong.  Failure  is  a node  failure.  ) 

Writ«St r ing^Par amOut , "TIME  TO  IMPLEMENT  NODE  FAILURE  ROUTINE"); 
WriteLn (ParamOut) ; 

WritaLn (ParamOut) ; 


END; 


END  TalkToRootP rocas s ; 

(.....****.*****.*.*******t********‘****************t******t***************) 


PROCEDURE  RootNodaProcess (RootNoda 

VAR  GoodRootNode 

Spawn ingQueue 

VAR  GrowModa 

VAR  DiagnosticStatus 

GrowToRootNodaRaaponse 

VAR  Node Status 


INTEGER; 

BOOLEAN; 

SpawningQueueType ; 
GrowNetwor kModeTypa ; 
Diagnos ticRecordTypa ; 
ChainStatusData; 
NodaStatus Array) ; 


VAR  Spawn in gE lament  : Spawn ingNode Type; 

BEGIN 

IF  NOT  GoodRootNode  THEN 

IF  ChainExecutedWithoutError (GrowToRootNodeRasponse)  THEN 


GoodRootNode  TRUE; 


(*  Put  Root  Node  on  the  Spawning  Queue.  *) 

NEW (SpawningElement) ; 

SpawningElamentA .Node  : “ RootNoda; 

INSERT  SpawningElement  LAST  IN  Spawn ingQueue; 

NodeStatus (FindNodaNumber (RootNoda) ] .Status  :«  Active; 


(*  A good  root  node  has  been  found, 
GrowModa 

DiagnosticStatus .Diagnostic 
DiagnosticStatus .TestNoda 
DiagnosticStatus .TestPort 
DiagnosticStatus .PortDiagnosticsRun 


change  modes . * ) 

Diagnos ticCheck; 
Lin kEn able; 
RootNoda; 

- 1; 

- FALSE; 


RunDiagnostic (DiagnosticStatus,  NodeStatus,  NodeConnect ions  ); 


ELSE 

WritaString (ParamOut,  "First  Root  Link  tried  "); 
Writes tring (ParamOut,  "was  bad."); 

WriteLn (ParamOut) ; 


END; 
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END; 


END  RootNodeProcess ; 


(♦**★**** ****t *********** 


* * ****************** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 


) 


PROCEDURE  AddNodeProcess (VAR  Grows tatus 

Response 

VAR  StatusOfDiagnostics 
VAR  Previous AddFailed 
VAR  No deStatus 
NodeConnections 


: NetworkGrowthProgressType; 
: ChainStatusData; 

: DiagnosticRecordType; 

: BOOLEAN; 

: NodeStatusArray; 

: NodeArrayType) ; 


VAR  Disconnect IORe quest  : IORequestType; 

RequestDisconnectNode  : DataPointer; 
Process ingDisconnectNode  : ProcessingUnit; 


BEGIN 


IF  ChainExecutedWi thou tError (Response)  THEN 


(*  Update  the  status  of  the  spawning  node  and  the  target 
node  as  a result  of  adding  the  new  node.  *) 


NodeStatus [ F in dNodeN umber (GrowStatus .TargetNode) ] .Status  Active; 


GrowStatus .Mode 
StatusOfDiagnostics .Diagnostic 
StatusOfDiagnostics . TestNode 
StatusOfDiagnostics . TestPort 
StatusOfDiagnostics . PortDiagnosticsRun 


- DiagnosticCheck; 

* LinkEnable; 

* GrowStatus. TargetNode; 

- 1; 

- FALSE; 


RunDiagnos tic (StatusOfDiagnostics,  NodeStatus,  NodeConnections); 


ELSIF  Previous AddFailed  THEN 
Previous AddFailed  : = FALSE; 

NextNodeToAdd (GrowStatus,  NodeConnections,  NodeStatus,  DIUList); 

ELSE 


{*  The  previous  try  to  connect  to  a node  was  unsucessful. 

Assume  that  the  link  is  broken.  Update  link  statuses  to  reflect  *) 
PreviousAddFailed  :«  TRUE;  * 


(*  Update  Status  of  the  two  nodes  that  were  unsuccuessfully 
added  to  the  network.  *) 

NodeStatus [FindNodeNumbar (GrowStatus . SpawningNode) ] .PortStatus [ 
GrowStatus .Spawn ingPort] .Status  Failed; 

NodeStatus [FindNodeNumber (GrowStatus . TargetNode) ] .PortStatus ( 
GrowStatus .Targe tPort] .Status  :«  Failed; 


DalataNodaFromNetwork  (GrowStatus . SpawningNoda,  GrowStatus . SpawningPort, 

GrowStatus. TargatNode,  GrowStatus .TargetPort,  NodeStatus,  DisconnactlORaquast) ; 


Disconnect IORequest A .ChainA .NetworkToBeExecutedOn 
Disconnect IORequest A . Identifier  MyNodelD; 
Disconnect IORequest A .ResponseExpected  :■  TRUE; 


NetworkIDToManage ; 


(*  Disconnect  failed  link.  *) 
NEW (RequestDisconnectNode) ; 
WITH  RequestDisconnectNodeA  DO 


Message  NetworkRequest; 

IORequest  :«  Disconnect IORequest; 
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END; 

NEW (Pro cess ingDisconnectNode) ; 


WITH  ProcessingDisconnectNodeA  DO 

Priority  Networ kManager Prior ity; 

Pr oces  s ingRequir ed  :*  CoraputeTwoTransactionChain 

+ NetworkResponseComputation; 

- FALSE; 

« 'NW  Disconnect  Node  Processing'; 
“ RequestDis  connectNode ; 


WriteData 
Process ID 
Data 


END; 

NOW  outport [IOPPort] A .ProcessorRequest  <-  ProcessingDisconnectNode; 


END; 


END  AddNodaProcess; 

(********.*****************************************‘***********************) 
PROCEDURE  AddDlUProcess (VAR  GrowStatus  : NatworkGrowthProgressType; 

Response  : ChainStatusData; 

VAR  NodeStatus  : Node Status Array) ; 


VAR  DIUE lament 

AddD IUIORequest 
GPCE lament 
AddGPCIOReques t 
AddD IURequest 
P roc es s AddD ID 
AddGPCRequest 
Process AddGPC 


DIUSpawningRecord; 

IORequestType; 

GPCSpawningRecord; 

IORequestType; 

DataPointer; 

ProcessingUnit; 

DataPointer; 

Pr oce  3 3 ingUnit ; 


BEGIN 

IF  ChainExecutedWithoutError (Response)  THEN 
DIUElement  FirstQ (DIUList) ; 

IF  DIUElement  <>  NIL  THEN 

REMOVE  DIUElement  FROM  DIUList; 

(*  Update  Status  of  node  that  is  conected  to  the  DIU  that 
is  being  added  to  the  network.  *) 

WITH  DIUElement A DO 

NodeStatus [FindNodeNumber (SpawningNode) ] . 

Ports tatus [OutboardPort] . Status  Active; 

NodeStatus [FindNodeNumber (SpawningNode) } . 

PortStatus [OutboardPort] .Direction  Outboard; 

AddD IUToNetwork (SpawningNode,  OutboardPort,  NodeStatus,  AddD IUIORequest) , 
(*  Data  Collection.  *) 

GrowStatus .DIUAddress  NodeConnections [FindNodeNumber (SpawningNode) ] . 
Por t Array [OutboardPort ]. DIUAddr ess; 


END; 


DISPOSE  (DIUElement) ; 

AddDIUIORequestA . Chain A .NetworkToBeExecutedOn 
AddD IUIORequest A .Identifier  :«  MyNodelD; 
AddDIUIORequestA .ResponseExpected  TRUE; 


NetworkIDToManage ; 


NEW (AddD IURequest) ; 

AddD IURequestA. Message  NetworkRequest; 

AddD IURequest A . IORequest  AddD IUIORequest; 


NEW (ProcessAddDIU) ; 

ProcessAddDIUA .Priority 
P roces s AddD IU A .Process ingRequired 


NetworkManagerPriority; 

ComputeOneTransactionChain 

+ NetworkResponseComputation; 

FALSE; 


ProcessAddDIUA .WriteData 


ProcessAddDIUA .ProcessID  'NW  Add  DIU  Processing'; 

ProcessAddDIUA .Data  AddDIURequest; 

NOW  outport (IOPPort] A .ProcessorRequest  <-  Process AddDIU; 


ELSE 


( DIUs  h^ve  been  added  to  the  network.  Now  add  the  GPC 

connections.  Set  mode  to  add  GPCs.  *} 

GrowStatus .Mode  :»  AddGPCS; 

GPCElement  FirstQ (GPCList) ; 

REMOVE  GPCElement  FROM  GPCList; 

(*  Update  status  of  the  node  connected  to  the  spare  root 
link  connection  to  be  added  to  the  network.  *) 

WITH  GPCElementA  DO 

NodeStatus (FindNodeNumber (SpawningNode) ] . 

PortStatus [ InboardPort] . Status  :«  Active; 

NodeStatus [FindNodeNumber (SpawningNode) ] . 

PortStatus [ InboardPort ]. Direction  !■  Inboard; 

AddGPCToNetwork  (SpawningNode,  InboardPortf  NodeStatus,  AddGPCIORequest) 

GrowStatus . Spar eRootNodeAddr ess  :■  SpawningNode; 


END; 


DISPOSE (GPCElement) ; 

AddGPCIORequest A .Chain A .NetworkToBeExecutedOn  NetworkIDToManage; 

AddGPCIORequest A . Identifier  MyNodelD; 

AddGPCIORequest A .Re sponsaExpected  : - TRUE; 


NEW (AddGPCRequest ) ; 

AddGPCRequest A .Message  :■  NetworkRequest ; 
AddGPCRequest A.I0RequQ3t  AddGPCIORequest; 


NEW (ProcessAddGPC) ; 

ProcessAddGPCA .Priority 
Process AddGPCA .ProcessingRequired 

ProcessAddGPC A .WriteData 
Pro cess AddGPCA .Process ID 
ProcessAddGPC A . Data 


•m  NetworkManagerPriority; 

:*  ComputeOneTransactionChain 

+ NetworkResponseComputation; 
FALSE; 

•m  /NW  Add  GPC  Processing'; 

:*  AddGPCRequest; 


NOW  outport [IOPPort] A .ProcessorRequest  <-  ProcessAddGPC; 


END; 


ELSE 


WriteString (ParamOut,  ’’Problems  encountered  enabling  a DIU.")* 
WriteLn (ParamOut) ; 


END; 


END  AddDIUProcess ; 


PROCEDURE  AddGPCProcess (VAR  GrowStatus  : NetworkGrowthProgressType; 

Response  : ChainStatusData; 

VAR  NodeStatus  : NodeStatusArray; 
MonitorChain  : ChainType); 


) 


VAR  GPCElement 

AddGPCIORequest 
AddGPCRequ  e s t 
ProcessAddGPC 
NewS tat eRequest 
ProcessNewState 


GPCSpawningRecord; 

IORequestType; 

DataPomter; 

ProcessingUnit; 

DataPointer; 

ProcessingUnit; 
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ChainExecutedWithoutError (Response)  THEN 
GPCElement  !■  FirstQ (GPCList) ; 


IF  GPCElement  O NIL  THEN 

REMOVE  GPCElement  FRCM  GPCList; 

(*  update  status  of  the  node  connected  to  the  spare  root 
link  connection  to  be  added  to  the  network.  ) 

WITH  GPCElementA  DO 

NodeStatus [FindNodeNumber (SpawningNode ) ] . 

PortStatus [ InboardPort] . Status  Active, 

NodeStatus [FindNodeNumber (SpawningNode) ] . 

PortStatus [InboardPort] .Direction  Inboard, 


AddGPCToNetwork (SpawningNode,  InboardPort,  NodeStatus,  AddGPC IOR.quest) 
crraistatns . SDareRootNodeAddress  SpawningNode; 


END; 

DISPOSE (GPCElement) ; , 

AddGPCIORequestA  .ChainA  .NetworkToBeExecutedOn 
AddGPCIORequest A . Identifier  :»  MyNodelD; 
AddGPCIORequestA  .ResponseExpected  TRUE; 


NetworkIDToManage ; 


HEW  (AddGPCRequest)  ; 
AddGPCRequest A .Message 
AddGPCRequest A . IORequest 


NetworkRequest ; 
AddGPC I OReque s t ; 


NEW (Process AddGPC) ; 

Process AddGPC A .Priority 

Proces s AddGPC A .ProcessingRequired 


NetworkManagerPriority; 

ComputeOneTransactionChain 

+ NetworkResponseComputat ion ; 


Process AddGPC A .WriteData 

Proces sAddGPCA .Process ID 
Pro cess AddGPC A .Data 


FALSE; 

:*  'NW  Add  GPC  Processing'; 
: - AddGPCRequest; 


NOW  outport [IOPPort] * .ProcessorRequest  <-  ProcessAddGPC 


ELSE 


(*  All  GPCs  have  been  added  to  the  network. 

that  my  network  is  now  operational.  *) 
NEW (NetworkState) ; 


Notify  the  I/O  Service 


NetworkStateA .NetworkID 

NetworkState A. St ate 
NetworkStateA .MonitorChain 


Ne  two  r k ID ToManage ; 

InService; 

MonitorChain; 


NEW  (NewStateRequest)  ; 
NewStateRequestA .Message 

NewStateRequest A .StataData 


NewState; 

NetworkState; 


NEW (ProcessNewState) ; 

ProcessNewStateA. Priority  ; 

Proces sNewStateA .ProcessingRequired 

Proces sNewStateA .WriteData 
Proces sNewStateA .ProcessID 
ProcessNewState A .Data 


NetworkManagerPr ior ity ; 
ChangeNetworkStatus 

+ NetworkResponseComputat ion; 

FALSE; 

' Change  Network  State'; 
NewStateRequest ; 


NOW 


outport [IOPPort] A -ProcessorRequest  <-  ProcessNewState; 


END; 


ELSE 


Writestring (ParamOut,  "Tried  to  add  a GPC  and  failed.") 


WriteLn (ParamOut) ; 


END; 


END  AddGPCProcess; 

jr^*******T********t,******“*************““*******'“********“******1 

( This  procedure  processes  a network  response  and  determines  what  the 
next  network  manager  action.  *) 

PROCEDURE  ProcessNetworkResponse (Response 

Mode 

VAR  StatusOf Growth 
VAR  StatusOfDiagnostics 


VAR  SpawningNode  : Spawn mgNodeType; 
BEGIN 


Chains tatus Data; 

Networ kManager JobType ; 
NetworkGrowthProgreasType ; 
DiagnosticRecordType) ; 


IF  Mode  - GROWNetwork  THEN 

CASE  StatusOf Growth .Mode  OF 
GrowToRootNode : 


RootNodeProcess (StatusOfGrowth. RootNodeAddress,  GoodRootNodeFound 
Spawn rngQueue,  StatusOfGrowth .Mode,  StatusOfDiagnostics, 
Response,  NodeStatus) ; f 

I AddReraainingNodes : 

AddNodaProcess (StatusOfGrowth,  Response,  StatusOfDiagnostics, 
PreviousChainFailed,  NodeStatus,  NodeConnections); 

I AddDIUS : 


AddDIUProcess (StatusOfGrowth,  Response,  NodeStatus); 

I AddGPCS: 

AddGPCProcess (StatusOfGrowth,  Response,  NodeStatus, 
StatusOfDiagnostics . TalkerRequest* .Chain) ; 

I DiagnosticCheck: 

IF  StatusOfDiagnostics .Diagnostic  <>  DiagnosticsComplete  THEN 

IF  StatusOf Diagnostics. Diagnostic  - DisabledTransmit  THEN 

StatusOfDiagnostics . LinkEnahleSucessf ul  : - 

ChainExecutedWithoutError (Response) ; 

END; 

RunDiagnostic (StatusOfDiagnostics,  NodeStatus, 

NodeConnections  } ; 

EISIF  QSize (Spawn ingQueue)  <>  0 THEN 

REPORT  "%d"  StatusOfDiagnostics .TestNode  TAGGED  "Node  added."; 
IF  NumberOf ActiveNodes  - 0 THEN 

(*  This  indicates  that  the  root  node  is  the  only 
node  in  the  network  and  the  other  nodes  have 
yet  to  be  added.  *) 

remove  FIRST  SpawningNode  FROM  SpawningQueue; 
StatusOfGrowth. SpawningNode  SpawningNode*. Node- 

StatusOfGrowth  . Spawn mgPort  :=  1; 

DISPOSE (SpawningNode) ; 


END; 
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NumberOfActiveNodes  Number  Of  Act  iveNodes  + 1; 

Statu sOf Growth .Mode  AddRemainingNodes; 

NextNodeToAdd(StatusOf Growth,  NodeConnect ions , NodeStatus, 
DIUList); 

END; 

END; 

ELSE 

CASE  RepairNetworkMode  OF 
DisconnectLink: 

DisconnectLinkProcess (ErrorReport,  Response,  NodeStatus, 
NodeConnections) ; 

1 ReconnectLink: 

ReconnectLinkProceaa (ErrorReport,  Response) ; 

| ReconnectBranch : 

ReconnectBranchProceas (ErrorReport,  Response) ; 

| TalkToRootFailedTree : 

TalkToRootProces s (Response,  BranchNode,  BranchPort) ; 

ELSE 


WriteString (ParamOut,  "DISCONNECT  LINK  IS  THE  ONLY  MODE  SUPPORTED") 
WriteLn (ParamOut) ; 

END; 


END; 


ReleaseChainResponseMemory (Response) ; 

END  ProcessNetworkResponse; 

(*************************i****  *************************************** *****) 

PROCEDURE  ReleaseManagerRequeat (VAR  Request  : IORequestType) ; 

VAR  Transaction  : TransactionType; 

Element Counter  : INTEGER; 

Number Of Element s : INTEGER; 


BEGIN 

IF  Request  <>  NIL  THEN 

WITH  Request A . Chain*  DO 

Number Of Elements  :=  QSize (TransactionQueue) ; 

FOR  ElementCounter  :«  1 TO  Number Of Elements  DO 

Transaction  QRemove (Tran s actio nQueue,  TRUE); 
DISPOSE (Transaction A .OutputFrame) ; 

DISPOSE (Transaction) ; 


END; 

QDispose (TransactionQueue,  SIZE (TransactionQueue) ) ; 


END; 

DISPOSE  (Request A .Chain) ; 


DISPOSE (Request) ; 


END; 


END  ReleaseManager Request; 


BEGIN 


IOPPort 


GetOutPort ( lOPIdantif ier ) ; 

RoadNodeInt«rConn«ctiona(N9tworkIDToManag»,  NodeConnections)  ; 
Iniiializ^tatusyariahlas  (NodeConnections,  NodaStatus,  ChannelStatus) ; 
Nodes  I nNet  work  : * NodeaTnThi  4.^  i mu  t a f i nn  ^ j i . 


WriteLn  (ParamOut)  ; 
WriteLn (ParamOut) ; 


Nodes InThisSimulation (NodeConnections ) ; 


DiagnosticStatus . TalkerRequest  : - MakeMonitorRequest (NodeConnections) ; 

WITH  DiagnosticStatus. TalkerRequest A DO 

Chain A . Networ kToBeExe cu t edOn  Network I DToManage; 

Identifier  MyNodelD; 

ResponseExpected  TRUE; 


END; 


NEW  (PowerupRequest ) ; 
PowerupRequestA. Message  :«  Powerup; 


NEW (PowerupProcess ing) ; 
PowerupProcessingA .Priority 
PowerupProcessingA .ProcessingRequired 
PowerupProcess ing A .WriteData 
PowerupProcessingA .Process ID 
PowerupProcessingA .Data 


2; 

- FLOAT (NodesInNetwork)  * NodePowerupInitilizeTioe; 
” FALSE; 

■ 'NM  Power  up' ; 

3 PowerupRequest; 


NOW  outport | IOPPort] A . ProcessorRaquest  <-  PowerupProcessing; 
LOOP 


WAITUNTIL  (ProcessorResponse) 

ProcessorResponse : 

ProcessingResponse  ActivePortA .ProcessorResponse; 
ProcessResponse  :=»  ProcessingResponseA .Data; 

IF  ProcessResponse* .Message  - Powerup  THEN 

EXIT; 


ELSE 

WnteString (ParamOut,  "Problem  during  NM  power  up  processing")  * 
WriteLn (ParamOut) ; 


END; 


END; 


END; 

DISPOSE (ProcessingResponse) ; 

DISPOSE (ProcessResponse) ; 

PreviousChainFailed  :=  FALSE; 

NumberOfActiveNodes  :«  0; 

(*  Initailize  the  Node  Status  variable  to  reflect  the  networks 
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intial  state.  *) 

FOR  Nodeindex  1 TO  Nodes I nNet work  DO 

WITH  NodeStatus (Nodal ndex]  DO 

Address  NodeConnect ions (Nodal ndax] .NodaAddr ass; 

Status  :«  Active; 

FOR  Portlndax  1 TO  NumberOfPortsPerNode  DO 

IF  InitialNodeConfiguration [Node Index] [Portlndax]  THEN 
PortStatus (Portlndax] .Status  Active; 

IF  InitialOriantation (Nodelndax] [Portlndax]  THEN 
PortStatus (Portlndex] .Direction  Inboard; 

ELSE 

PortStatus (Portlndex] .Direction  :«  Outboard; 

END; 

ELSE 

PortStatus (Portlndex] . Status  :■  Idle; 

END; 


END; 


END; 


END; 

LOOP 


WAITUNTIL  EVENT 

Service Request : 

RequestFor Service  ActivePort* . ServiceRaquest; 

CASE  RequestForService* .ServiceRaquest  OF 
GrowNetwork: 

InitializeStatusVariables (NodeConnections , NodeStatus , 
ChannelStatus ) ; 

GoodRootNodeFound  : “ FALSE; 

NatworkManagerStatus  ■ “ GROWNetwork; 

Ne two rkGrowthPr ogress .Mode  :»  GrowToRootNode; 

StartNetvorkGrowth (RequestForServicaA .ActiveRootLink, 
NetworkGrowthPr ogres  s , NodeConnections , NodeStatus , 
NodesInNetwork) ; 

| RepairFault : 

{*  This  reconfiguration  strategy  attempts 
one  shot  repair  of  the  network.  *) 

NatworkManagerStatus  :»  RepairNetwork; 

AnalysisPortDecisions  0; 

NetworkRepair (RequestFor Service A .MonitorChainResponseA .Response, 
NodeStatus,  NodeConnections,  ErrorReport, 

RepairNetworkMode)  ; 

| SwitchRootLink : 

WITH  RequestForServiceA  DO 


(*  Get  the  node  which  is  connected  to  the  new 
root  link  and  the  node  connected  to  the  failed 
Un*'  Deternine  which  port  ot  RootNode 
which  is  connected  to  the  NewRoot.  *) 

RootNode  :»  FindNodeNumber (NewRootNode) ; 
FailedNode  : - FindNodeNumber  (FailedRootNode) ; 

CurrentPort  :•  1; 

WHILE  NodeConnections [RootNode] .PortArravf 
CurrentPort] . Ad jacentEl ament  O GPC  DO 

CurrentPort  CurrentPort  + 1; 

END; 


{•Update  node  status  to  reflect  the  root  link  switch  *> 
UpdateNodeStatusBranchReconnect (NodeStatus [RootNode] .Addriss 
CurrentPort,  NodeStatus [FailedNode] .Address  ' 

NodeStatus); 

END; 

DISPOSE (RequestForService)  ; 

| IONetworkResponse : 

NetworkResponse  ActivePortA . IONetworkResponse; 

^^Networ^r^^0"5*  (N6tWOricRe3P°n3e'  NetworkManagerStatus, 
NatworkGrowthPrograas,  DiagnosticStatus) ; 

(•  Get  rid  of  memory  for  I/O  request  corresponding  to 
this  response.  *)  y 

ReleaseManagerRequest (LastNetworkRequest) ; 

ProceasorResponse : 

ProcessingResponse 
ProcessResponse 


1 ActivePortA. ProceasorResponse; 
1 ProcessingResponse* .Data; 


CASE  ProcessRespon3eA . Message  OF 

GrowRequest,  NetworkRequest,  FaultAnalysis : 
WITH  DataCollectionRecord  DO 


SimulationTime 

Frequency 


clock; 

NonCyclic; 


IF  NetworkManagerStatus  > GROWNetwork  THEN 
NonCyclicData . N_Variation  RegrowAction; 

CASE  NetworkGrowthProgress .Mode  OF 
GrowToRootNode : 

Event  ID  3 2 . 

NonCyclicData. Node_DIU_ID' N^workGrowthProgress  -RootNodeAddress; 
WriteDataElementType (DataCollectionRecord) ; 

| AddRemamingNodes  : 

Event  ID  ..  33. 

NonCyclicData  .Node_DIU_ID ' N^workGrowthProgress  . TargetNode; 

Wr iteDat aElemen  tType (DataCollectionRecord) ; 


1 AddDIUS: 


WriteDataElementType  (DataCollactionRecord) ; 


| AddGPCS : 


Event ID 

NonCyclicData  .Noda_DIU_ID 


35; 

:»  NetworkGrowthProgress 


. SpareRootNodaAddres  s ; 


WriteDataElaoentType (DataCollactionRecord) ; 


ELSE 


END; 

ELSIF  NetworkHanagerStatus  - RepairNetwork  THEN 
CASE  RepairNatworkMode  OF 
DisconnactLink: 


EvantID  ;«  36;  , 

Rrrorlndax  • * 1/ 

FOR  Nodalndex  1 TO  Nodes InNetwork  DO 

IF  ^ErrorReport Tault Analys isRacord . FailedNodeSat  THEN 

NonCyclicData . Noda_ID (Error Index]  NodeConnactions (Nodalndex] .NodaAddrass; 


END; 


END; 


WriteDataElamantType (DataCollactionRacord) ; 


EvantID 


37; 


essees?1 *£££££■ . ^ 

SourceNode  100  ♦Transaction'' .OutputFrama  .Address, 

NonCyclicData . Link_Node_ID  SourcaNoda  + TargatNoda; 


RaconnectLink : 

EvantID  ’** 

NonCvc licDat a . N_Var iat ion 

=~  HSSSsapa 

NonCyclicData. Link_Node_ID  SourceNode  + TargatNoda, 


OnaShotAction,^^^  .chain*. TransactionQueue)  ; 


. TransactionQueue 


| RaconnactBranch : 

Eva  nt ID  i * 3 9 ; , t 

^^attiof %NFiHtSprocess^s5n^  . Request* -Chain* .TransactionQueua)  ; 

SEES. ::  Ec^sess., 

TaraetNode  :»  Transaction A .OutputFrama  -Addr  ' 

NonCyclicData . Link_Node_ID  SourceNode  + TargatNoda, 


ChainA .Trans act ionQueue 


| TalkToRootFailedTrae: 


EM  49 


Event ID  40; 

NonCy c licData . N_Var iat ion  OnaShotAction; 

TaroatNod*0  !’  j[irstQ  <Proc®ssR»»Ponse- . IORaqueat- .Chain ' 
TargetNode  : - Transaction- . OutputFraae- . Address ; 
NonCyclicData . Link  Node  ID  TargetNode* 


END; 

WriteDataElamentType (DataCollectionRecord) ; 

END; 


END; 

^»»^°rvi1]A'I0NetWOrkRe<IUe3t  <-  ProcassRasponso-.IORequest; 
LastNetworkRequest  ProcassResponseA  . IORaouast- • 


ProcassResponseA . IORequest; 


NewState 


NOW  outport [1] - .NevNetworkStata  <-  ProcessRasponse-.StateData; 

END; 

DISPOSE (ProcesaingRaaponse) ; 

DISPOSE (ProcessResponae) ; 

I Raaat : 

(*  Rasat  manager7 a view  of  the  network.  *) 

(*  Reinitailize  tha  Node  Status  variable  to  reflect 
the  network7 s intial  state.  *) 

PreviousChainFailed  FALSE; 

NumberOfActiveNodea  0; 

InitializeStatus Variables (NodaConnections,  NodeStatus,  ChannelStatus ) ; 
FOR  Nodeindex  1 TO  Nodes InNetwork  DO 
WITH  NodaStatua [Nodeindex]  DO 
Status  :*  Active; 

FOR  Portlndex  :*  1 TO  NumberOfPortsPerNode  DO 

IF  InitialNodeConfiguration [Nodalndex] [Portlndax]  THEN 
PortStatua [Portlndex] . Status  :■  Active; 

IF  InitialOriantation [Nodalndex] [Portlndex]  THEN 
PortStatus [Portlndex] .Direction  :*  Inboard; 

ELSE 


PortStatus [Portlndax] .Direction  Outboard; 

END; 


ELSE 


PortStatus (Portlndex] .Status  :■  Idle; 


END; 


END; 

END; 


END; 


END; 


. TransactionOuaue) 


B-150 


END; 


END  N®tMang®r . 


BLDCHAINS 


DEFINITION  MODULE  BldChains; 

FROM  IOSarvica  IMPORT  IORaquastTypa; 

FROM  BusMessag  IMPORT  IOActivityChoica; 

EXPORT  QUALIFIED  ApplicationTypa,  BuildRaquest; 

TYPE  ApplicationTypa  ■ (F lightContr ol , EngineControl) ; 

{ttttttt*******************************************************************) 

PROCEDURE  BuildRaquaat  (Application  : ApplicationTypa; 

Rata  : INTEGER; 

IOActivity  : IOActivityChoica)  ; IORaquestType; 

(t****************************************t********************************) 


END  BldChains . 


BLDCHAINS 


IMPLEMENTATION  MODULE  BldChaina; 

FROM  IOServica  IMPORT  IOActivityTypa,  IORaqu eat Type; 


FROM  IOS  IMPORT  ChainTypa,  TranaactionTypa; 

FROM  BuaMeaaag  IMPORT  BuaMaaaagaType,  MaaeagaType,  IOActivityChoice 


FROM  QueuaM  IMPORT  InitQ,  QInaert,  QSize; 

FROM  Storage  IMPORT  ALLOCATE ; 

CONST  FlightControlRequeatTimeoutlOO 
FlightControlRaqueatTiaaoutSO 
FlightControlRequaatTimeout25 

EngineContro  lRequaa tTinaout  100 
EngineContro IRequea  tTimaout 5 0 
EnginaContro IRequea  t T imeout2 5 

EngineControlIdantifierlOO 

EngineControlIdentifierSO 

EngineControlIdentifier25 

FlightControlIdantifiarlOO 

FlightControlIdentifierSO 

FlightControlIdentifier25 

InlatRaquastPriority 

NozzleRequestPriority 

EngineRaquestPriority 

Faa tRaquaa tP rior ity 
MiddleRequea tPr ior ity 
SlowRequestPriority 

InletDIUAddr  aas  1 
NozzlaDIUAddraaa 1 
EngineD IUAddraa a 1 
InlatDIUAddreaa2 
NozzlaDIUAddraaa 2 
EngineDIUAddr aa a 2 

Sanaor 2DIUAddras s 1 
Cockpit2DIUAddreasl 
CanardRightD  IUAddr  a 3 a 1 
LaadingEdgaRightD  IUAddraa  a 1 
OutboardF laperonRigh tD IUAddrasa 1 
Inboar dFlaperonRightD IUAddraa a 1 
TrailingEdgeRigh tD IUAddra a a 1 
RudderR-ightD  IUAddra  a a 1 
RuddarLaftD IUAddraa 5 1 
TrailingEdgaLef tDIUAddraaa 1 
Inb oar dFlaparonLaf tD IUAddraa a 1 
OutboardF laparon La f tD I UAddraa a 1 
NoaaDIUAddreaal 
CanardLaftDIUAddraaal 
CockpitlD IUAddraa si 
Sanaor lDIUAddras  a 1 

Sanaor 2DIUAddres a 2 
Cockpit2DIUAddraas2 
CanardRightD IUAddr a a a 2 
LaadingEdgaRightDIU Addraa  a2 
OutboardF lap aronRightD IUAddr a a a 2 
InboardFlaparonRightD I UAddraa  a 2 
TrailingEdgeRigh tDIUAddraaa 2 

RuddarRightD IUAddraa s2 
Ruddar Laf tD IUAddr aa a 2 
TrailingEdgaLaf tD IUAddraa  a2 

I nboar dFlapa r onL a f tD IU Addr a s a 2 
OutboardF lap aro n La f tD I UAddraa a 2 


- 0.002, 
- 0.002, 
- 0.001 

- 0.001 
- 0.001 
- 0.001 

- 100; 

- 50; 

- 25; 

- 100; 

- 50; 

- 25; 

- 10; 

- 9; 

- 8; 


10; 

9; 

8; 


- 81; 

- 83; 

- 82; 

- Ill; 

- 113; 

- 112; 


- 91; 

- 92; 

- 93; 

- 94; 

- 95; 

- 96; 

- 97; 

- 98; 

- 99; 

- 100 
- 101 
- 102 

- 103 

- 104 

- 105 

- 106 

- Ill; 

- 112; 

- 113; 

- 114; 

- 115; 
« 116 ; 

- 117, 

- 118, 

- 119, 

- 120 
- 121 
- 122 


NoseDIUAddress2 
Can ardLeftD IUAddr ess 2 
Cockp i t ID IUAddr  e 5 a 2 
Sensor ID IUAddr es 3 2 


123; 

124; 

125; 

126; 


(*  This  section  controls  the  transaction  timeouts  of  for  transactions 
in  the  flight  control  and  engine  application.  *) 

(*  This  section  sets  transaction  timeouts  for  the  engine  application. 
Since  there  is  only  one  transaction  in  each  of  the  chains, 
timeouts  will  be  set  at  maximum  execution  time  plus 
time  for  response  bits  on  the  bus  plus  10%  of  the  previos  sum  *) 

InletTran s act ion Timeout  - 0.000305;  (*  max  0.000277  *) 

NozzleTransact ionTimeout  - 0.000229;  (*  max  0.000208  *) 

EngineTr ansa ct ion Timeout  - 0.000637;  {*  max  0.000579  *) 


(*  This  sections  sets  the  transaction  timeouts  for  the  flight 
control  application.  The  timeouts  are  set  such  that  if  a 
transaction  times  out,  the  succeding  transaction  in  the  chain 
for  the  network  with  the  failed  transacton,  will  be 
transmitted  from  the  IOS  approximately  the  same  time  as  the 
corresponding  transaction  on  the  unfailed  network.  *) 
Sensor2FastTransactionTimeout  - 0.000208 

Senaor2MiddleTransactionTimeout  - 0.000116 

Cockpit2TranaactionTimeout  - 0.000139 

CanardRightTrans act ion Timeout  « 0.000116 

LeadingEdgeRightTransactionTimeout  - 0.000208 

OutboardF laperonRight Transact ionTimeout  - 0.000139 
Inboar dFlaperonRightTransact ionTimeout  - 0.000162 

TrailingEdgeRightTrans act ionTimeout  « 0.000162 

Rudder RightTransact ionTimeout  « 0.000116 

RudderLeftTransact ionTimeout  - 0.000116 

TrailingEdgeLeftTransactionTimeout  ■ 0.000139 

InboardFlaperonLeftTransactionTimeout  - 0.000162 

OutboardF laperonLeft Transact ion Time out  - 0.000139 

Nos eTrans act ionTimeout  . 0.000116 

CanardLef tTr ansae t ionTimeout  - 0.000116 

CockpitlMiddleTransactionTimeout  - 0.000139 

Cockpit IS lowTransactionTimeout  - 0.000093 

Sensor lFastTransact ionTimeout  - 0.000208 

SensorlHiddleTransactionTimeout  - 0.000116 

Sensor lSlowTransact ionTimeout  « 0.000093 


<********************************** ********************************** 

PROCEDURE  FltConlOORequest (IOActivity  ; IOActivityChoica)  : IORequestType; 

VAR  FlightControllOORequest  : IORequestType; 

Network IChain  : ChainType; 

Network2Chain  : ChainType; 

Transaction  ; TransactionType; 

Command  : BusMessageType; 


BEGIN 


(*  This  process  controls  the  100Hz  I/O  request.  I/O  Requests  will 
be  generated  at  a 100Hz  rate,  i.e  every  10ms.  After  the  I/O 
response  is  received,  this  process  will  delay  for  a time  interval 
Intended  to  represent  the  time  it  takes  to  generate  the  next  output. 

NEW (FlightControllOORequest) ; 

NEW  (Network IChain) ; 

NEW  (Network 2 Chain)  ; 


Networkl Chain * .TransactionQueue 
Network2 Chain A .TransactionQueue 
NetworklChainA .Chainldentif ier 
Network2ChainA .Chainldentif ier 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  CommandA  DO 


InitQ ("TransactionQueue",  FALSE,  0) ; 
InitQ ("TransactionQueue”,  FALSE,  0) ; 

l; 
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Address  SensorlDIUAddressl; 
Message  :*  DlUlnput; 

WITH  DIUCommand  DO 

Activity  IOActivity; 

CommandNumber  1; 


END; 


END; 

WITH  Transaction*  DO 

Identifier  :«  100; 

TimeOutValue  :=  SensorlFastTransactionTimeout, 

OutputFrame  ;■  Command; 


END; 

Qlnsert (Transaction,  NetworklChain^.TransactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  :*  Sensor 2DIUAddressl; 

Message  :■  DlUlnput; 

WITH  DIUCommand  DO 

Activity  ■*  IOActivity; 

CommandNumber  :■  1; 


END; 


END; 


WITH  Transaction*  DO 

Identifier  101;  , . 

TimeOutValue  Sensor2FastTransactionTimeout; 

OutputFrame  :*  Command; 


END; 

Qlnsert (Transaction,  NetworklChain* .TransactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW  (Command)  ; 

WITH  Command*  DO 

Address  OutboardFlaperonLeftDIUAddressl; 

Message  :m  DlUlnput; 

WITH  DIUCommand  DO 

Activity  :«  IOActivity; 

CommandNumber  :■  1; 


END; 


END; 


WITH  Transaction*  DO 

TimeOutValue  ^oardFlaperonLeftTransactionTimeout; 

OutputFrame  :■  Command; 


END; 


Qlnsart (Transaction,  NetworklChain* .Transact ionQueue,  FALSE) 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  DO 

Addrass  OutboardFlaperonRightDIUAddressl ; 

Mas saga  :»  DID Input; 

WITH  DlUCommand  DO 


Activity  IOActivity; 

CommandNumber  :*  1; 


END; 


END; 

WITH  Transaction*  DO 

Identifier  103; 

TimaOutValue  :*  OutboardFlaperonRightTransactionTimeout; 

OutputFrame  :»  Command; 


END; 

QInsert (Transaction,  NetworklChain* .TransactionQueue,  FALSE); 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  IX) 

Address  InboardFlaperonLeftDIUAddressl; 

Massage  DIU Input; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandNumber  : ® 1; 


END; 


END; 

WITH  Transaction*  DO 
Identifier  104; 

TimaOutValue  :»  InboardFlaperonLeftTransactionTimeout ; 
OutputFrame  :=  Command; 


END; 

QInsert (Transaction,  NetworklChain* .Transact ionQueue,  FALSE) ; 

NEW (Transaction) ; 

NEW  (Command)  ; 

WITH  Command*  DO 

Address  :«  InboardFlaperonRightDIUAddressl; 

Message  :=  DIU Input; 

WITH  DlUCommand  DO 

Activity  :=  IOActivity; 

CommandNumber  :=  1; 


END; 
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END; 


WITH  Transaction*  DO 

Identifier  ;■  105;  _ , 

TimeOut  Value  InboardFl^eronBlghtTransactionTimeout; 

OutputFrame  :■  Command; 


END; 

QInsert (Transaction , NetworklChain* .TransactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  :■  TrailingEdgeLeftDIUAddressl; 

Message  DIU Input; 

WITH  DIUCommand  DO 

Activity  IOActivity; 

CommandNumber  :■  1; 


END; 


END; 


WITH  Transaction*  DO 

Identifier  :■  106; 

TimeOut Value  :«  TrailingEdgeLeftTransactionTimeout, 

OutputFrame  :m  Command; 


END; 

QInsert  (Transaction,  NetworklChain''  .TranaactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  :«  TrailingEdgeRightDIUAddressl ; 

Message  DIU Input; 

WITH  DIUCommand  DO 

Activity  :■  IOActivity; 

CommandNumber  1; 


END; 

END; 

WITH  Transaction*  DO 

Identifier  ;■  107;  . . . 

TimeOutValue  : - TrailingEdgeRightTransactionTimeou  , 

OutputFrame  :■  Command; 

END; 

QInsert (Transaction,  NetworklChain* . Transact ionQueue , FALSE) 

(*  INSERT  Transaction  LAST  IN  NetworklChain* -TranactionQueue) ; 

*) 

WITH  Networ klChain * DO 
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NetworkToBeExecutedOn  1; 

NumbarOf Transact ions  QSiza (NetworklChain* . TransactionQuaua) 


END; 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  Sensor lDIUAddress2; 
Message  :»  DlUInput; 

WITH  DlUCommand  DO 

Activity  :*  IOActivity; 

CommandNumbar  :*  1; 


END; 


END; 

WITH  TransactionA  DO 

Identifier  200; 

TimeOut Value  Sensor lFastTransactionTimeout; 

OutputFrame  :«  Command; 


END; 

QInsert  (Transaction,  Networ)c2Chain*  .TransactionQueue,  FALSE); 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  :«  Sensor2DIUAddress2; 

Message  :«  DlUInput; 

WITH  DlUCommand  DO 

Activity  :«  IOActivity; 

Comman dN umber  : * 1 


END; 


END; 

WITH  Transaction*  DO 

Identifier  :=  201; 

TimeOutValue  :*  Sensor2FastTransactionTimeout; 
OutputFrame  : * Command; 


END; 

QInsert  (Transaction,  Network2Cham*  .TransactionQueue,  FALSE); 

NEW (Transaction)  ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  OutboardFlaperonLeftDIUAddress2; 

Message  :«  DlUInput; 

WITH  DlUCommand  DO 

Activity  : = IOActivity; 

CommandNumber  :=  1; 


END; 
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END; 


WITH  Transaction*  DO 

TimeOutValue  !-  OutboardJlaparonLaftTransactionTuiiaout; 

OutputFrama  :*  Command; 


END; 

Q Insert (Transaction,  Network2ChainA .TransactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  OutboardFlaperonRightDIUAddress2  ; 

Mas saga  :■  DIU Input; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandNumber  :■  1 ; 


END; 


END; 

WITH  Transaction*  DO 

TimaOut Value  OutboardFlaperonRightTransactionTimeout , 

OutputFrama  :■  Command; 


END; 

QInaart  (Transaction,  NetworWCbain* .TransactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  InboardFlaperonLeftDIUAddress2; 

Message  DlUInput; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandNumber  : » 1 ; 


END; 


END; 


WITH  Transaction*  DO 


Identifier 

TimeOutValue 

OutputFrama 


Inboar  dFlaperonLeftTrans act ionTimeout; 

Command; 


END; 

Qlnsert (Transaction,  Network2Chain* .TransactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 
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Address  InboardFlaperonRightDIUAddress2; 
Message  :»  DlUInput; 

WITH  DlUCommand  DO 

Activity  :«  IOActivity; 

CommandNumber  :»  1; 


END; 


END; 

WITH  TransactionA  DO 

Identifier  : = 205; 

TimeOutValue  I nbo ar dF lap ere nRight Trans act ion Timeout; 

OutputFrame  : = Command; 


END; 

QInsert (Transaction,  Network2ChainA .Transact ionOueue,  FALSE) 

NEW(Transaction); 

NEW (Command) ; 

WITH  CommandA  DO 

Address  TrailingEdgeLeftDIUAddress2; 

Message  DlUInput; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandNumber  : ■ 1; 


END; 


END; 

WITH  TransactionA  DO 
Identifier  206; 

TimeOutValue  :=*  TrailingEdgeLeftTransactionTimeout; 
OutputFrame  :»  Command; 


END; 

QInsert (Transaction,  Network2ChainA .TransactionQueue,  FALSE) ; 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command A DO 

Address  :=»  TrailingEdgeRightDIUAddress2; 

Message  :=  DlUInput; 

WITH  DlUCommand  DO 

Activity  :=  IOActivity; 

CommandNumber  1; 


END; 


END; 

WITH  TransactionA  DO 

Identifier  : = 207; 

TimeOutValue  :»  TrailingEdgeRightTransactionTimeout; 
OutputFrame  Command; 
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END; 


(* 

*) 


QInsert (Transaction,  Network2ChainA .Transact ionQueue,  FALSE); 
INSERT  Transaction  LAST  IN  Network2 Chain A .TranactionQueue) ; 


WITH  Networ k2Chain A DO 

NetworkToBeExecutedOn 
NumberOfTransactions  :■ 


2; 


QSize (Network2ChainA . TransactionQueue) ; 


END; 


WITH  FlightControllOORequestA  DO 


Priority 
Identifier 
RequestTimeoutValue 
RequestType 
ChainArray |1] 
ChainArray [2] 


FastRequestPriority; 
FlightControlIdentif ierlOO;  ; 
FlightControlRequestTimeoutlOO ; 
App  1 icat  io  nRe  qua  s t ; 

Network lChain ; 

Network2Chain ; 


END; 


RETURN  (FlightControllOORequest) ; 


END  FltConlOORe quest; 

(«*...*********************************************************t***********) 
PROCEDURE  FltCon50Raquest (IOActivity  : IOActivityChoice)  : IORequestType; 


VAR  FlightControl50Request 
Network lChain 
Network2 Chain 
Transaction 
Command 


IORequestType; 

ChainType; 

ChainType; 

TransactionType; 

BusMessageType; 


BEGIN 


i.  This  process  controls  tha  50Hz  I/O  Request.  I/O  Requests  will  be 

' ganaratad  at  a 50Hz  rata,  i.a  avary  10ms.  Aftar  tha  I/°  ™«pon« 

is  racaivad,  this  procass  will  dalay  for  a time  interval  intended 

to  represent  tha  time  it  takes  to  generate  the  next  output.  ) 


NEW (FlightControlSORequest) ; 

NEW (Network lChain) ; 

NEW (Network2Chain) ; 

N e two r kl Chain A . Transact ionOueue 
Network2ChainA .TransactionQueue 
NetworklChainA . Chainldantif ier 
Network2 Chain A .Chainldantif ier 


InitQ ("Transact ionOueue” , FALSE,  0); 
InitQ ("TransactionQueue” , FALSE,  0) ; 
2; 

2; 


NEW (Transaction) ; 

NEW  (Command)  ; 

WITH  CommandA  DO 

Address  Sensor lDIUAddressl; 
Message  :«  DIU Input; 

WITH  DlUCommand  DO 


Activity  •*  IOActivity; 

CommandNumber  2; 


END; 
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END; 


WITH  Transaction  DO 

Identifier  :=»  100; 

TimeOutValue  :■  SensorlMiddleTransactionTimeout; 
OutputFrame  Command; 


END; 


QInsert (Transaction,  NetworklChain* .TransactionQueue,  FALSE); 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  : - Sensor2DIUAddressl; 

Message  DIU Input; 

WITH  DlUCommand  DO 


Activity  :«  lOActivity; 

CommandNumber  2; 


END; 


END; 


WITH  TransactionA  DO 

Identifier  101; 

TimeOutValue  Sensor2MiddleTransactionTimeout; 

OutputFrame  :=*  Command; 


END; 

QInsert (Transaction,  NetworklChain* . TransactionQueue,  FALSE); 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  Cockpit iDIUAddressl; 

Message  DlUInput; 

WITH  DlUCommand  DO 

Activity  : = lOActivity; 

CommandNumber  :*  2; 


END; 


END; 

WITH  Transaction*  DO 

Identifier  :»  102; 

TimeOutValue  Cockpit lMiddleTransactionTimeout; 

OutputFrame  Command; 


END; 

QInsert (Transaction,  NetworklChain* . Transact ionQueue,  FALSE); 

NEW (Transaction ) ; 

NEW (Command) ; 

WITH  Command*  DO 
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Address  Cockpit2DIUAddressl; 
Message  ■ ■ DlUInput; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandN umber  : * 2 ; 


END; 


END; 


WITH  Transaction*  DO 

Identifier  :«  103; 

TimeOut Value  Cockpit2TransactionTimeout; 

OutputFrame  :*  Command; 


END; 

Qlnsert (Transaction,  NetworklChain* .TransactionQueue, 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  CanardLeftDIUAddressl; 

Message  ;■  DlUInput; 

WITH  DlUConunand  DO 

Activity  !"  IOActivity; 

CommandN umber  : - 2 ; 


END; 


END; 


WITH  Transaction*  DO 

Identifier  104; 

TimeOut Value  CanardLeftTransactionTimeout, 

OutputFrame  Command; 


EHD; 

Qlnsert (Transaction,  NetworklChain* . TransactionQueue 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  :»  CanardRightDIUAddressl; 

Message  :*  DlUInput; 

WITH  DlUCommand  DO 

Activity  :=*  IOActivity; 

CommandN umber  : - 2; 


END; 


END; 

WITH  Transaction*  DO 

Identifier  105; 

TimeOut Value  CanardRightTransactionTimeout, 

OutputFrame  :■  Command; 


FALSE) ; 


FALSE) 


END; 


QInsert (Transaction,  Net worklChain*. Tran sac tionQueue,  FALSE) ; 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  Rudder LeftDIUAddrea si; 

Message  :«  DlUInput; 

WITH  DIUCommand  DO 

Activity  :»  IOActivity; 

CommandN umber  : « 2 ; 


END; 


END; 


WITH  TransactionA  DO 

Identifier  106; 

TimeOutValue  :»  RuddarLeftTransactionTimeout; 
Output? rame  : - Command; 


END; 

QInsert (Transaction,  Network iChain* .Transact ionQueue,  FALSE) ; 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  :«  RudderRightDIUAddressl ; 

Message  :»  DlUInput; 

WITH  DIUCommand  DO 

Activity  IOActivity; 

CommandN umber  : * 2 ; 


END; 


END; 

WITH  Transaction*  DO 
Identifier  :=*  107; 

TimeOutValue  RudderRightTransactionTimeout; 

OutputFrame  Command; 


END; 

QInsert (Transaction,  NetworklChain* . Transact ionQueue,  FALSE); 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  :«  NosaDIUAddressl; 

Message  DlUInput; 

WITH  DIUCommand  DO 

Activity  IOActivity; 

ConunandNumber  : * 2 ; 


END; 
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END; 


WITH  Transaction*  DO 

Identifier  108; 

TimeOut Value  NoseTransactronTimeout; 

OutputFrame  Command; 


END; 

QInsert (Transaction,  NetvorklChain* . Transact ionQuaua,  FALSE) 

NEW (Transaction) ; 

NEW  (Command)  ; 

WITH  Command*  DO 

Address  :»  LeadingEdgeRightD IU Addr e s s 1 ; 

Message  :*  DIU Input; 

WITH  DlUCommand  DO 

Activity  *■  IOActivity, 

CommandNumber  ;■  2; 


(* 

*) 


END; 

END; 

WITH  Transaction*  DO 

TimaOutValua  LeadingEdgeRightTransactionTimeout; 

OutputFrame  :*  Command; 

END; 

Qlnsert (Transaction,  NetworlclChain*  - Transact  ionQueua,  FALSE) 
INSERT  Transaction  LAST  IN  NatworklChain* .TranactionQuaua) ; 


WITH  NetworklChain*  DO 

NetworkToBeExecutedOn 

NumberOfTransactions 


1; 


QSize  (NetworklChain''.  Transact  ionQueue)  ; 


END; 

NEW (Transaction) ; 

NEW  (Command)  ; 

WITH  Command*  DO 

Address  :=  SensorlDIUAddrass2; 
Massage  :**  DlUInput; 

WITH  DlUCommand  DO 

Activity  :«  IOActivity; 

CommandNumber  ■ * 2 ; 


END; 


END; 


WITH  Transaction*  DO 

TimaOutValua  i-  SensorlMiddlaTransactionTimeout; 

OutputFrame  Command; 
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END  ; 


QInsert (Transaction,  Network2ChainA .Transact ion Queue,  FALSE) 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command^  DO 

Address  Sensor 2DIUAddress2; 

Message  :»  D IU Input; 

WITH  DIUCommand  DO 


Activity  :«  IOActivity; 

CommandNumber  :■  2; 


END; 


END; 

WITH  Transaction A DO 
Identifier  :«  201; 

TimeOutValue  Sensor 2MiddleTransactionTimeout; 

OutputFrame  Command; 


END; 

QInsert (Transaction,  Network2ChainA .Transact ion Queue,  FALSE); 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  CommandA  DO 

Address  :«  CockpitlDIUAddress2; 

Message  ;«  DlUInput; 

WITH  DIUCommand  DO 

Activity  IOActivity; 

CommandNumber  :«  2; 


END; 


END; 


WITH  TransactionA  DO 

Identifier  :=*  202; 

TimeOutValue  :*  Cockpit lMiddleTransactionTimeout ; 
OutputFrame  : = Command; 


END; 

QInsert (Transaction,  Network2ChainA . Transact ionQueue,  FALSE); 

NEW (Transaction) ; 

NEW  (Command)  ; 

WITH  CommandA  DO 

Address  Cockpit2DIUAddress2 ; 

Message  DlUInput; 

WITH  DIUCommand  DO 

Activity  : = IOActivity; 

CommandNumber  :=«  2; 
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END; 


END; 


WITH  Transaction*  DO 

Identifier  203; 

TimeOutValue  :»  Cockpit 2TransactionTameout, 
OutputFrame  :»  Command; 


END; 

Q Insert (Transaction,  N«tWork2Chain* . Transact lonQueue,  FALSE) 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  CanardLef tDIUAddress2; 

Massage  ;»  DIDInput; 

WITH  DIUCommand  DO 

Activity  J-  IOActivity ; 

CommandNumbar  ; ■ 2; 


END; 


END; 


WITH  Transaction*  DO 

Identifier  204;  . 

TimeOut Value  CanardLeftTransactionTimeout; 

OutputFrame  : - Command; 


END; 

QInsert  (Transaction,  Network2Chain''  .TransactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  CanardRightDIUAddrass2 ; 

Massage  :«*  DIU Input; 

WITH  DIUCommand  DO 

Activity  IOActivity; 

CommandNumber  2; 


END; 


END; 

WITH  Transaction*  DO 

Identifier  205;  . 

TimeOut Value  CanardRightTransactionTimeout; 

OutputFrame  ;■  Command; 


END; 

QInsert (Transaction,  Network2Chain* .TransactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 
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Address  RudderLef tDIUAddress2; 

Message  D IU Input; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandNumber  2; 


END; 


END; 

WITH  Transaction A DO 

Identifier  206; 

TimeOutValue  : = RudderLeftTransactionTimeout; 
OutputFrame  Command; 


END; 

QInsert (Transaction,  Network2ChainA .TransactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  CommandA  DO 

Address  RudderRightDIUAddrass2 ; 

Message  DlUInput; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandNumber  :»  2; 


END; 


END ; 

WITH  Transaction**1  DO 

Identifier  :*  207; 

TimeOutValue  :*  RudderRightTransactionTimeout; 
OutputFrame  :=»  Command; 


END; 

QInsert (Transaction,  Network2ChainA . Transact ionQueue,  FALSE); 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  CommandA  DO 

Address  NoseDIUAddress2; 

Message  :=  DlUInput; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandNumber  :*=  2; 


END; 


END; 

WITH  TransactionA  DO 

Identifier  :=  208; 

TimeOutValue  : = NoseTransactionTiraeout; 
OutputFrame  :■  Command; 
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END; 


QInsart (Transaction,  Network2Chain* .TransactionQueue,  FALSE); 

NEW (Transaction) ; 

NEW  (Command)  ; 

WITH  CommandA  DO 

Address  LeadingEdgeRightDIUAddress2; 

Message  :*  DIU Input; 

WITH  DlUCommand  DO 

Activity  s-  IOActivity; 

CommandNumber  :*  2 ; 


END; 


END; 


WITH  Transaction A DO 


Identifier  :*  209; 

TimeOutValue  LeadingEdgeRightTransactionTuseout, 

OutputFrame  ;■  Command; 


END; 

QInsart (Transaction,  Natwork2ChalnA .Transact ionQuaua,  FALSE); 


(* 

*) 


INSERT  Transaction  LAST  IN  Network2ChainA .TranactionQueue) ; 


WITH  Network2ChainA  DO 

NetworkToBeExecutedOn 

Number 0 f Tr an s a ct i on s 


2; 

QSire (Ne two rk2 Chain 


A . TransactionQueue ) 


END; 


WITH  FlightControl50RequestA  DO 


Priority 
Identifier 
Request! imeout Value 
RequestType 
ChainArray [1] 
ChainArray [2] 


MiddleRequestPriority; 
FlightControlIdentif ier 50 ; 
FlightControlRequestTimeoutSO; 
App  1 ica  t io  nRe  que  s t ; 
NetworklChain ; 

Network2Chain; 


END; 


RETURN  (FlightControl50Request) ; 


END  FltConSORequest; 


PROCEDURE  FItCon25Raquast (IOActivity  : IOActivityChoica)  : IORequestType; 


VAR  FlightControl25Request  ; IORequestType; 

NetworklChain  : ChainType; 

Network2Chain  : ChainType; 

Transaction  : Transact ionType , 

Command  : BusMessageType; 


BEGIN 

(*  This  process  controls  the  25Hi  I/O  Request.  *1/0  Requests  will  be 
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generated  at  a 25Hz  rate,  i.e  every  40ms.  After  the  I/O  response 
is  received,  this  process  will  delay  for  a time  interval  intended 
to  represent  the  time  it  takes  to  generate  the  next  output.  *) 

NEW(FlightControl25Request) ; 

NEW (Network lChain) ; 

NEW (Network2 Chain) ; 

NetworklChainA .Transact ionQueue  InitQ( "Trans act ionQueue",  FALSE,  0) ; 

Networ k2 Chain A .Transact ionQueue  In itQ {"Transact ionQueue",  FALSE,  0); 

NetworklChainA .Chainldentifier  3; 

Net wo rk2 Chain A .Cha inidentifier  3; 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command A DO 

Address  Sensor IDIUAddres si; 

Message  :=*  DlUInput; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandNumber  :«  3; 

END; 

END; 

WITH  TransactionA  DO 

Identifier  100; 

TimeOutValue  :»  SensorlSlowTransactionTimeout; 

OutputFrame  Command; 

END; 

QInsert (Transaction,  NetworklChainA . Transact ionQueue,  FALSE); 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command A DO 

Address  : * Cockpit IDIUAddres si ; 

Message  :»  DlUInput; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandNumber  :*  3; 

END; 

END; 

WITH  Transaction A DO 

Identifier  :*  101; 

TimeOutValue  :*  Cockpit lSlowTransactionTimeout; 

OutputFrame  : -=  Command; 

END; 

QInsert  (Transaction,  Networ  klChamA  .Transact ionQueue,  FALSE); 

WITH  NetworklChamA  DO 

NetworkToBeExecutedOn  :=  1; 

NumberOf Transactions  : « QSize (NetworklChainA .TransactionQueue) ; 

END; 
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NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  :■  SensorlDIUAddress2; 
Message  :*  DlUInput; 

WITH  DlUCommand  DO 

Activity  •**  IOActivity; 

CommandNumber  :m  3; 


END; 


END; 

WITH  Transaction*  DO 

Identifier  200; 

TimeOutValue  SensorlSlowTransactionTimeout, 

OutputFrame  im  Command; 


END; 

QInsert (Transaction,  Network2Chain* .TransactionQueue,  FALSE) 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  Cockpit ID IUAddress 2 ; 

Message  :*  DlUInput; 

WITH  DlUCommand  DO 

Activity  •“  IOActivity; 

CommandNumber  :*  3; 


END; 


END; 

WITH  Transaction*  DO 

TimeOutValue  CockpitlSlovrtransactionTimeout; 

OutputFrame  Command; 


END; 


QInsert (Transaction,  Network2Chain* .TransactionQueue,  FALSE); 
WITH  Ne t wo rk.2 Chain*  DO 


NetworkToBeExecutedOn 

MiimherOf Transact  ions 


2; 

HQ  1 TA  (Natwork2Chain* . TransactionQueue) , 


END; 


WITH  FlightControl25Request*  DO 


Priority 
Identifier 
Request Timeout Value 
RequestType 
ChainArray (1) 
ChainArray (2) 


- S lowReques  tP  r ior i ty ; 

- FlightCont rol Identifier 25; 

= FlightControlRequestTimeout25; 
**  ApplicationRequest; 

« Network lChain ; 

» Network2Chain; 


END; 
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RETURN  (FlightControl25Request) ; 

END  FltCon25Request; 

(*************,*****.******. *********„****„  *******.**„*,*,»»,«**,*,****** 

PROCEDURE  EnginelOORequest (IOActivity  : IOActivityChoice)  : IORequestType; 

VAR  EngineControll OORequest  : IORequestType ; 

: ChamType; 

: ChainType; 
r TransactionTypa; 

■ BusMessageType; 

BEGIN 


werworxiunain 

Network2Chain 

Transaction 

Command 


( This  process  controls  the  inlet,  which  is  designated  as  DIU  address 
81  on  network  1 and  DIU  address  91  on  network  2.  I/O  Requests  will 
be  generated  at  a 100Hz  rate,  i.e  every  10ms.  After  the  I/O 
response  is  received,  his  process  will  delay  for  a time  interval 
intended  to  represent  the  time  it  takes  to  generate  the  next  output. 


(*  Initialize  the  Inlet  Chain  which  has  three  actuator  writes 
and  six  sensor  reads.  *) 

NEW (EngineControll OORequest) ; 

NEW (Network lChain) ; 

NEW {Network2 Chain) ; 


NetworklChainA .TransactionQueue 
Network2 Chain A . TransactionQueue 
Networklchain* .Chainldentif ier 
Network2 Chain A .Chainldentif ier 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 


In itQ ("TransactionQueue",  FALSE,  0); 
InitQ ("TransactionQueue",  FALSE,  0) ; 

1; 


Address  InletDIUAddressl ; 
Message  :■  DIU Input; 


WITH  DIUCommand  DO 


Activity  :*  IOActivity; 

CoramandN umber  :=  1; 


END; 


END; 

WITH  TransactionA  DO 
Identifier  :■  100; 

TimeOutValue  ;*  InletTransactionTimeout; 
OutputFrame  :■  Command; 


END; 

QInsert (Transaction,  Networklchain* .TransactionQueue,  FALSE); 

WITH  NetworklChain A DO 

NetworkToBeExecutedOn  :»  1; 

NumberOf Transactions  QSize (NetworklChain" .TransactionQueue) ; 

END; 

NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command A DO 

Address  :=■>  InletDIUAddress2  ; 

Message  :*  DlUInput; 
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WITH  DIUCommand  DO 


Activity  :■  IOActivity; 

Comman  dNumber  :■  1# 


END; 


END; 

WITH  TransactionA  DO 

Identifier  200; 

TimeOut Value  InletTransactionTuneout; 

OutputFrame  :■  Command; 


END; 

QInsert (Transaction,  Network2ChainA .TransactionQueue,  FALSE); 
WITH  Networ k2 Chain A DO 


END; 


WITH  EngineControl 100RequestA  DO 


Priority 

Identifier 

RequestType 

Request Timeout Value 
RequestType 
ChainArray [1] 
ChainArray [2] 


InletRequestPriority ; 
EngineControl Identif ier 100 ; ; 
ApplicationRequest; 

EngineControlRequestTimeoutlOO; 

ApplicationRequest; 

Net work 1 Chain; 

Network2Chain ; 


END; 


RETURN  (EngineControllOORequest) ; 


END  EnginelOORequest; 

(*«*» *********************** ***************************** 
PROCEDURE  EngineSORequest (IOActivity  : IOActivityChoica) 


**************** 
: IORequestType; 


**) 


VAR  EngineControl50Request 
Network lChain 
Network2Chain 
Transaction 
Command 


IORequestType; 
ChainType; 
ChainType; 
TransactionType ; 
BusMessageType; 


BEGIN 


This  process  controls  the  inlet,  which  is  designated  as  DIU  address 
82  on  network  1 and  DIU  address  92  on  network  2 . I/O  Requests  will 
be  generated  at  a50Hz  rate,  i.e  every  10ms.  After  the  I/O  response 
is  received,  this  process  will  delay  for  a time  interval  intended  to 
represent  the  time  it  takes  to  generate  the  next  output.  ) 


(*  Initialize  the  Nozzle  Chain  which  has  three  actuator  writes 
and  six  sensor  reads.  *) 

NEW (EngineControl 5 ORequest) ; 

NEW (NetworklChain) ; 

NEW (Network2Chain) ; 


NetworklChainA -TransactionQueue 
Network2 Chain A .TransactionQueue 

NetworklChainA .Chainldentif ier 

Network2ChainA .Chainldentif ier 


InitQ ("TransactionQueue",  FALSE,  0) ; 
InitQ ("TransactionQueue",  FALSE,  0) ; 
2; 

2; 


NEW (Transaction)  ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  NozzleDIUAddressl; 

Massage  DlUInput; 

WITH  DlUCommand  DO 

Activity  :«  IOActivity; 

CommandN  umber  :*  2; 


END; 


END; 

WITH  Transaction*  DO 

Identifier  :»  100; 

TimaOut Value  :»  NozzleTransactionTimeout; 
OutputFrame  : » Command; 


END; 

QInsert (Transaction,  NetworJcl Chain*. Tran sactionQueua,  FALSE); 

WITH  NatworJcl  Chain*  DO 

Na twor JcToBaExa  cu t edOn  ;»  1; 

NunborOf Transactions  QSrze (Networklchain" . Tr ansae tionQuaue) 

END; 

NEW (Transaction) ; 

NEW  (Command) ; 

WITH  Command*  DO 

Address  NozzleDIUAddress2 ; 

Message  DlUInput; 

WITH  DlUCommand  DO 

Activity  IOActivity; 

CommandN umber  :*  2; 


END; 


END; 

WITH  Transaction*  DO 
Identifier  200; 

TimaOutValue  NozzleTransactionTimeout ; 

OutputFrame  Command; 


END; 

QInsert (Transaction,  Natwor)c2Chain* .Transact ionQueuo,  FALSE); 

WITH  Network2Chain  * DO 

NetworkToBeExecutedOn  :*  2; 

NumberOf Transact ions  : = QSize <Network2Chain* . TransactionQuaue) ; 

END; 

WITH  EngineControlSORequest*  DO 

Priority  NozzieRequestPriority; 

Identifier  :*  EngineControIIdentif ier50; 

RequestType  :•  ApplicationRequest; 

RequestTimeout Value  EngineControlRequestTimeoutSO; 
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ChainArray [1] 
ChainArray [2] 


Network IChain ; 
Networ k2 Chain; 


END; 


RETURN  (EngineControlSORequest) ; 


END  EngineS ORequest; 

(s*************************************************************************1 
PROCEDURE  Engine25Request (IOActivity  : IOActivityChoice)  : IORequestType; 


VAR  EnginaControl25Raquest 
Network IChain 
Network2Chain 
Transaction 
Coma and 


: IORequestType; 

: ChainType; 

; ChainType; 

: TransactionType; 
: BusMes sage Type; 


BEGIN 


This  process  controls  the  inlet,  which  is  designated  as  DIU  address 
83  on  network  1 and  DIU  address  93  on  network  2.  I/O  Requests  will 
be  generated  at  W5 Hz  rate,  i.e  every  10ms.  After  the  I/O  response 
is  received,  this  process  will  delay  for  a time  interval  intended  to 
represent  the  time  it  takes  to  generate  the  next  output.  > 


* Initialize  the  Engine  Chain  which  has  three  actuator  writes 


and  six  sensor  reads.  *) 

NEW (EngineControl2  SRaquast ) ; 

NEW (Network IChain) ; 

NEW (Network2Chain) ; 

NetworklChain* .TransactionQueue 
Network2 Chain A .TransactionQueue 
NetworklChain* .Chainldentif ier 
Ne two rk2 Chain* .Chainldentif iar 


InitQ ("TransactionQueue",  FALSE,  0) ; 
InitQ ("TransactionQueue",  FALSE,  0)  ; 

3; 

3; 


NEW (Transaction) ; 

NEW (Command) ; 

WITH  Command*  DO 

Address  :*  EngineDIU Address 1 ; 
Message  ;■  DlUInput; 


WITH  DIUCommand  DO 

Activity  :*  IOActivity; 

C oiiul an dN umber  :*  3; 


END; 


END; 

WITH  Transaction*  DO 

Identifier  :*  100; 

TimeOutValue  :■  EngineTransactionTimaout ; 
OutputFrame  :•  Command; 


END; 

QInsert (Transaction,  NetworklChain* .TransactionQueue,  FALSE); 
WITH  NetworklChain*  DO 


NetworkToBeExecutedOn 
NumberOf Transactions 


1; 


QSize (NetworklChain* . TransactionQueue ) ; 


END; 

NEW (Transaction) ; 


NEW  (Command) ; 

WITH  Command*  DO 

Address  EngineDIUAddress2; 
Message  DIU Input; 

WITH  DlUCommand  DO 

Activity  :«  IOActivity; 

CoomandNumber  3; 


END; 


WITH  Transaction*  DO 

Identifier  :=■  200; 

TimeOutValue  :»  Engine Trans act ion Timeout ; 
OutputFrame  :=■  Command; 


END; 


QInsert (Transaction,  Network2  Chain* . Transact ionQueue,  FALSE) ; 

WITH  Network2 Chain*  DO 

NetworkToBeExecutedOn  :«  2; 

NumberOf Transact ions  : - QSxze (NetworklChain * . TransactionQueue ) ; 

END; 


WITH  EngineControl25Request*  DO 

Priority  EngineRequestPriority; 

Identifier  :»  EngineControlIdentifier25; 

RequestType  ApplicationRequest; 

Request  Timeout  Value  :=■  EngineControlRequestTimeout25; 
RequestType  ApplicationRequest; 

ChainArray [ 1 ] NetworklChain; 

ChainArray (2 j Networ k2Chain; 


END; 

RETURN  (EngineControl25Request) ; 

END  Engine25Request; 

(*********♦****************♦★********♦**************************★********** 

PROCEDURE  BuildRequest (Application  : ApplicationType; 

Rate  : INTEGER; 

IOActivity  : IOActivityChoice)  : IORequestType; 

VAR  Request  : IORequestType; 

BEGIN 

CASE  Application  OF 


FlightControl: 

CASE  Rate  OF 
100: 

Request  FltConl OORequest ( IOActivity) ; 

I 50: 

Request  :*  FltConSORaquest ( IOActivity) ; 
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I 25: 


Request  FltCon25Request (IOActivity) ; 

END; 

| EngineControl: 

CASE  Rate  OF 
100: 

Request  Engine lOORequest (IOActivity) ; 

| 50: 

Request  :*  Engine50Raquest (IOActivity) , 

| 25: 

Request  Engine25Re quest (IOActivity) ; 

END; 


END; 


Request* .RasponseExpected  NOT  (IOActivity  - Output); 
RETURN  (Request) ; 

END  BuildRequeat; 


END  BldChains. 
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APPLICATN 


DEVM  Applicatn; 

FRCM  IOSarvica  REACH  IORequeatTypa* , IORaaponseTypa*,  ChainStatusTypa, 

Re le as eCha inRa spona eMemory ; 

FRCH  Processor  REACH  Process ingUnit*; 

FRCM  BusMessag  IMPORT  lOActivityChoice; 

FROM  BldChaina  IMPORT  ApplicationTypa,  BuildRequaat; 

FRCM  Sanddata  IMPORT  WritaDataElaaantTypa,  CyclicDataTypa,  DataElamentTypa, 
CvclicVariationType,  FrequencyType; 


INPUTS 

EVENT 

RasponsaApplication  : IORasponsaTypa; 

ProcaasorRasponaa  : ProcaaaingUnit; 
Re  set  BOOLEAN; 

PARA 

CP  ID 

10 Service  ID 
P r oce s s i ngTimeMean 
P r oce s s ingT ime S igma 

EngineApplication 

OnDemand 

GroupedlOActivity 
ApplicationPriority 
IORequest Interval 
InitialOff set 
Appli cat ion Identifier 

END; 

OUTPUTS 

VAR  _ 

RequestApplication  : IORequestType; 
ProcessorRequest  : Process ingUnit, 


INTEGER; 

INTEGER; 

PEAL; 

REAL; 

BOOLEAN- 

BOOLEAN; 

BOOLEAN; 

INTEGER; 

REAL; 

REAL; 

INTEGER; 


END; 


EVENT 

CurrentFrame  : INTEGER; 


CONST 

Frame  Startup  Time 


0.000020; 


VAR 

ApplicationResponse 
ApplicationRequest 
ApplicationlnputRequest 
Appli cat ionOutputRequest 
PartialData 

ProcessingRequest 
CP  Res  pon  s eD  a ta 
TempRequest 
CPPort 

IOServicePort 
OutputDataE lament 

There I sAFrameExecu ting 


IOResponseType ; 

IORequestType; 

IORequestType; 

IORequestType; 

BOOLEAN; 

Process ingUnit; 
Process ingUnit; 
IORequestType; 
INTEGER; 

INTEGER; 

DataElementType ; 
BOOLEAN; 


********t*********** 


t**********************************4******************1 


PROCEDURE  CommunicationFaults (Reaponae  : IOReaponaaTypa)  : BOOLEAN; 


BEGIN 


WITH  Response A DO 

RETURN  ( Chains tatua [1]  <>  NoFaults)  OR  (ChainStatua[2]  <>  NoFaults) 


END; 


END  CommunicationFaults; 

(***********  ************************************ttt*tttt1k*#tttt1ktttt##tttttj 


PROCEDURE  VerifyCorrectResponse  (Response  : IOResponseType) ; 

BEGIN 

IF  GroupedlOActivity  THEN 

IF  (Response^. Identifier  o ApplicationRequest A . Identifier)  OR 
(QSize (Response A .ResponseArray (l] A . InputFrameQueue)  <> 

ApplicationRequestA . Chain A .NumberOf Transactions)  OR 
(QSize (Response A . ResponseArray (2] A . InputFrameQueue)  <> 

ApplicationRaquestA . ChainA .NumberOfTransactions)  THEN 

WriteString (ParamOut,  "Unexpected  response  received  from  the  10  System"); 
WriteLn (ParamOut) ; 

HALT; 

END; 

ELSIF  (Response^ Identifier  <>  ApplicationInputRaquestA . Identifier)  OR 
(QSize (Response A .ResponseArray ( 1]A . InputFrameQueue)  O 

AppiicationlnputRequest A . ChainA .NumberOf Transactions)  OR 
(QSize (Response A . ResponseArray [ 2 ] A . InputFrameQueue)  O 

ApplicationInputRequestA . Chain A .NumberOf Transactions)  THEN 

WriteString (ParamOut,  "Unexpected  response  received  from  the  10  System"); 
WriteLn (ParamOut) ; 

HALT; 


END; 

END  VerifyCorrectResponse; 

(***************** ********** *************************************** ***t****j 

BEGIN 

CPPort  GetOutPort (CPID) ; 

IOServicePort  GetOutPort ( IOServicelD) ; 

TherelsAFrameExecuting  FALSE; 

IF  GroupedlOAct ivity  OR  NOT  OnDemand  THEN  (*  Scheduled  10  must  use  GroupedIO  *) 

IF  EngineApplication  THEN 

ApplicationRequest  :«  BuildRequest (EngineControl,  Application Identifier,  Grouped); 
ELSE 

^ApplicationRaquast  BuildRequest (FlightControl,  Applicationldentifier,  Grouped); 

IF  Applicationldentifier  » 100  THEN 

ApplicationRequest A . ChainArray ( 1 ) A . Chainldentif ier  :»  !;■ 

ApplicationRequest A .ChainArray (2] A .Chainldentifier  :*  1; 

ELSIF  Applicationldentifier  « 50  THEN 

ApplicationRequest A .ChainArray [1] A. Chainldentifier  2; 

ApplicationRequest A . ChainArray ( 2 ] A . Chainldentifier  2; 

ELSIF  Applicationldentifier  =-  25  THEN 

ApplicationRequest A . ChainArray [ 1 ] A . Chainldentifier  :»3; 

ApplicationRequestA .ChainArray [2] A .Chainldentifier  3; 

END; 
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ApplicationRequestA .OnDemand  OnDemand; 
ELSE  (*  separated  10  Activity  *) 


IF  EngineApplication  THEN 
Application I npntRequest 
ApplicationOutputRe quest 

ELSE 

ApplicationlnputRequest 
ApplicationOutputRequest 
END  ; 


BuildRequest (EngineControl,  Applicationldentifier , Input ), 
BuildRequest (EngineControl,  Applicationldentifier,  Output); 


BuildRequest (FlightControl,  Applicationldentifier,  Input); 
BuildRequest (FlightControl,  Applicationldentifier,  Output), 


100  THEN 


IF  Applicationldentifier 

ApplicationlnputRequest* . ChainArray [1] 


*. Chainldentifier 


A^licationInputRequestA  .ChainArray  [2]  A .Chain Identifier  : 
A^licationOutputRequestA  . ChainArray  [ 1 ) .Chainldentifier 
ApplicationOutputRequestA .ChainArray [2]  .Chainldentifier 


5; 

5; 

- 9; 
* 9; 


ELSIF  Applicationldentifier  - 50  THEN 

ApplicationlnputRequest* . ChainArray [ 1 ] A .Chainldentifier  : 

^plicationlnputRaquest* . ChainArray  [2]  A.CharnIdentifiar: 

ApplicationOutputRequest* .ChainArray [1]  -Chainldentifier 

ApplicationOutputRequest* .ChainArray [2]  .Chainldentifi 


ELSIF  Applicationldentifier  - 25  THEN 

ApplicationlnputRequest* -ChainArray  [lj A .a^n  Identifier 


ApplicationlnputRequest A .ChainArray [2] 

ApplicationOutputRequestA .ChainArray { 1] A .Chainldentifier 
^plicationOutputRequest A . ChainArray [2 ] A . Chainldentifier 


- 7; 

- 7; 

11; 

11; 


END; 

Application  I nputRequestA.  OnDemand  :«  OnDemand; 
ApplicationOutputRequestA .OnDemand  OnDemand; 


END; 


LOOP 


WAITUNTIL  EVENT 
CurrentFrame: 

AFTER  IORequestlnterval  CurrentFrame  <-  CurrentFrame  + 1; 

IF  OnDemand  THEN 

IF  There Is AFrame Executing  THEN 

report  "%d"  CurrentFrame  TAGGED  "frame  overrun  at  frame  number 


ELSE 


NEW(ProcessingRequest) ; 
ProcessingRequestA .Priority 
Process ingRequestA .ProcessID 
Process ingRequest A .Frame 


Application? rior it y; 

"FrameStartup" ; 

Process  ingRequest”  .frame  j-*  CurrentFrame; 

ProcessinqRequest* .WriteData  TRUE; 


IF  GroupedlOActivity  THEN 

ProcessingRequest* .Data  ApplicationRequest; 

ELSE 

ProcessingRequest* .Data  ApplicationlnputRequest; 
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END; 


NOW  outport [CPPort] A .ProcessorRequest  <-  ProcessingRequest; 
There Is AFrameExecuting  TRUE; 


END; 


ELSE  {*  scheduled  10  *) 

ApplicationRequest A . Frame  CurrentFrame; 

ApplicationRequest A . ChainArray [ 1 ] A . FrameCount  CurrentFrame; 

ApplicationRequest A .ChainArray  [2] A .FrameCount  :■  CurrentFrame; 

NOW  outport  [IOSarvicePort]  A .RequestApplication  <-  ApplicationRequest; 

END; 

I ResponseApplication: 

ApplicationResponse  ActivePortA  .Respons explication; 

(*  Schedule  use  of  the  processor.  *) 

IF  OnDemand  THEN 

ProcessingRequestA . Process ingRequired  : - ProcessingRequestA .ProcssngAfterBlock * 

Process ingRequestA .WriteData  FALSE; 

ProcessingRequestA .ProcessID  "Response  Processing"; 

NOW  outport [CPPort] A .ProcessorRequest  <-  ProcessingRequest; 

ELSE  {*  scheduled  10  *) 

IF  There Is AFrameExecuting  THEN 

REPORT  "%d"  CurrentFrame  TAGGED  "frame  overrun  at  frame  number”; 

OutputDataElement .CyclicData .FrameOverrun  ;■  TRUE; 

ELSE 

NEW (ProcessingRequest) ; 

ProcessingRequest A .Priority  ApplicationPriority; 

ProcessingRequest A .Frame  :«  ApplicationResponseA .Frame; 

Process ingRequaa t * . Process ingRequ irad  Normal (1,  ProcessingTimeMean,  ProcassingTlaoSigna)  • 

ProcessingRequest  . ProcssngAfterBlock  0.0;  * ' ' 

ProcessingRequest A .WriteData  :*  TRUE; 

ProcessingRequestA. ProcessID  :*  "Response  Processing"; 

NOW  outport [CPPort] A. ProcessorRequest  <-  ProcessingRequest; 

There Is AFrameExecuting  TRUE; 

OutputDataElement .CyclicData . FrameOverrun  :»  FALSE; 

END; 


END; 


PartialData  :»  CommunicationFaults (ApplicationResponse) ; 
IF  NOT  PartialData  THEN 


Verif yCorrectResponse (ApplicationResponse) ; 

END; 

(*  Dispose  of  the  memory  in  the  Application  Response.  *) 

IF  ApplicationResponseA . ResponseArray [1]  <>  NIL  THEN 

ReleaseChainResponseMemory (ApplicationResponseA .ResponseArray [ 1] ) ; 

END; 
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IF  ApplicationResponseA.ResponseArray(2]  <>  NIL  THEN 
ReleaseChainRespons eMemory  (ApplicationResponseA  .ReaponseArray  ( 2 ] ) ; 


END; 

DISPOSE(ApplicationReaponae) ; 

| ProceaaorResponse : 

CPResponseData  ActivePort* .ProcessorResponse; 

IF  OnDemand  THEN 

IF  CPReaponseDataA -WriteData  THEN 

TampRequest  ;*  CPRaaponsaDataA . Data; 

TampRaqueat A .Frame  CPRasponsaDataA .Frame; 

TampRequest* .ChainArray[l] * .FrameCount  CPResponseData  .Frame; 

TampRequest*.ChainArray[ 2]*. FrameCount  CPResponseData  -Frame, 

NOW  outport ( IOSarvicePort] A .RequastApplication  <-  TempRequest; 


ELSE 


clock; 


CASE  Applicationldentifier  OF 
100:  OutputDataElamant .Event ID 
l 50:  OutputDataElamant .Event ID 
| 25:  OutputDataElemant .Event ID 
END; 

OutputDataElamant . SimuiationTime 
OutputDataE lement . Frequency  :■  Cyclic;  _ _ 

OutputDataElamant. CyclicData. FramaCount  CPResponseData  .Frame, 

OutputDataElamant. CyclicData. C_Variation  Endcomputing; 

OutputDataElamant. CyclicData. PartialDataUsedThisFrama  PartialData, 
OutputDataElamant. CyclicData. FrameOvarrun  CPResponseData  .Frame  <>  CurrentFrame 
OutputDataElamant. CyclicData. ProcassingNotCompletod  0.0; 

WritaDataElamentTypa (OutputDataElamant) ; 

TharelsAFramaExacuting  FALSE; 

IF  (NOT  GroupedlOActivity ) AND 

(ApplicationOutputRequestA. Chain*. NumberOfTransactions  <>  0)  THEN 


ADDlicationOutputRequest*. Frame  CPResponseData* .Frama;  A . 
ApplicationOutputRequest* . Chain Array ( 1 ] * .FramaCount  : - CPResponseData^  Frame , 
ApplicationOutputRequest* . ChainArray [2 ] * .FramaCount  CPRasponseData  .Frai 

NOW  outporti  IOSarvicePort]*. Request  Application  <-  ApplicationOutputRequest 


CPReaponaeDataA .Frame; 


END; 

DISPOSE (CPResponseData) ; 


END; 

ELSE  (*  scheduled  10  *) 

CASE  Applicationldentifier  OF 
100:  OutputDataElemant . Event ID 
| 50:  OutputDataE lament .Event ID 
j 25:  OutputDataElemant .Event ID 
END; 

OutputDataE lement . Simula tionTime 
- . V *-  rrAniian/<1l  * C 


clock; 


OutputDataElement. Frequency  Cyclic;  „ 

OutputDataElement. CyclicData. FrameCount  :=  CPResponseData  .Frame, 
OutputDataE  lement.  CyclicData.C_Variat  ion  EndComputing; 
OutputDataElement. CyclicData. PartialDataUsedThisFrame  PartialData, 

OutputDataElement. CyclicData. ProcessingNotCompleted  0.0; 
WriteDataElementType (OutputDataElement) ; 

TherelsAFrameExecuting  FALSE; 

DISPOSE (CPResponseData) ; 


END; 


! Resot  : 

There  I sAFramaExe  exiting  FALSE; 

REPORT  "%12.8f"  clock  TAGGED  M Application  started  at  " 
AFTER  Initial Off set  CurrentFrama  <-  1; 

END; 

END; 

END  Applicatn . 
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CONTROLS 


DEFINITION  DEVM  Controls; 

EXPORT  SystemProbe,  Number Of Probes; 

CONST 

NumberOf Probes  - 4; 

VAR 

SystemProbe  : ARRAY  [1  ..  Number Of Probes]  OF  AProbe; 
END  Controls . 
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DEVM  Controls; 

FROM  Sanddata  IMPORT  StaxtCollectingData,  FlushDataStructure,  EndCollactingData, 

WriteDataElementType,  DataElementTypa,  NonCyclicVariationType 
FrequencyType; 

FROM  BuaMessag  IMPORT  NumberOfNodes ; 

FROM  Math  IMPORT  RaalMod; 

FROM  Util  IMPORT  GatSaadValua,  SatSaadValuo; 

FROM  NodaM  IMPORT  Ranio vaAr  c r RastoraArc; 

FROM  Convaraions  IMPORT  RealToDFloat; 


INPUTS 

EVENT 

NetworkReady  : BOOLEAN; 


PARA 


Application ID 

ARRAY  [1  ..  3]  OF  INTEGER; 

IOSID 

ARRAY  [1  ..  6]  OF  INTEGER; 

NetworklNodaa 

ARRAY  | 1 . . NumbarOfNodaa ] 

Network2Nodes 

ARRAY  (1  ..  NumbarOfNodaa] 

IOSarvicalD 

INTEGER; 

NetworkManager2 ID 

INTEGER; 

CP  ID 

INTEGER; 

I OP  ID 

INTEGER; 

Experiment Inf o 

ARRAY  [1  ..  4]  OF  INTEGER; 

StartRunNuabar 

INTEGER; 

EndRunNumbar 

INTEGER; 

UsalnitialSaad 

BOOLEAN; 

Initial Sead 

INTEGER; 

Simulation Length 

REAL; 

LinkFaults 

BOOLEAN- 

SourcaFaultNode 

INTEGER; 

DastFaultNoda 

INTEGER; 

StartCPFDIRTime 

REAL; 

StartlOPFD IRTixne 

REAL; 

Sy a t amRapo r t La va 1 

INTEGER; 

OF  INTEGER; 


END; 

OUTPUTS 

VAR 

ReaatCommand  : BOOLEAN; 

SubmitSystam  : BOOLEAN; 

RasetProbaCommand  : BOOLEAN; 

END; 


EVENT 


Restart  : INTEGER; 

InsartFault  ; BOOLEAN; 

StopSimulation  : BOOLEAN; 

StopProba  : BOOLEAN ; 

CONST 

MajorFramaLangth  - 0.040; 
SecondMajorFrame  - 0.050; 


VAR 


ApplicationPort 

ARRAY  [1 

IOSPort 

ARRAY  [I 

IOServicaPort 

INTEGER; 

NatworkManager2Port 

INTEGER; 

IOPPort 

INTEGER; 

CPPort 

INTEGER; 

Node Index 

INTEGER; 

IOS Index 

INTEGER; 

• . 3]  OF  INTEGER; 
. . 6]  OF  INTEGER; 


B-190 


Node ID  : INTEGER; 

FaultTime  • REAL ; 

TimeToNextMajorFrame  : REAL; 

NextMa  jorFrame  : REAL; 

StartDataElement  : DataElementType; 

TarmPataElement  : DataElementType; 

Index  INTEGER; 


BEGIN 

IOServicePort  : - GetOutPort ( IOServicelD) ; 

NetworkManager2Port  :«  GetOutPort (Net workManager2 ID) ; 

IOPPort  :«  GetOutPort (IOP ID) ; 

r*ppr>rt>  ! ■ GetOutPort  (CP ID) ; 

FOR  Index  1 TO  3 DO 

ApplicationPort [Index]  GetOutPort (Application ID [Index] ) ; 


END; 

FOR  IOSIndex  :■  1 TO  6 DO 

IOSPort { IOSIndex]  GetOutPort (IOSID [IOSIndex]); 


END; 


FOR  NodelD  1 TO  MaxNodelD  DO 

ReportLevel [Node ID]  -1;  (*  turn  off  the  report  control  *) 


END; 


TermDataElement. Event ID  41; 

TermDataElement .Frequency  NonCyclic; 

TermDataElement .NonCyclicData .N_Variation  RunTerm; 

StartDataElement . Event  ID  : - 0 ; 

StartDataElement .Frequency  NonCyclic; 

StartDataElement .NonCyclicData.N_Variation  : - RunStart; 

StartDataElement .NonCyclicData . FaultTime  :«  0.0; 
StartDataElement .NonCyclicData.FirstFDIR  StartCPFDIRTime; 

LOOP 


WAITUNTIL  EVENT 
NetworkReady ; 

IF  UselnitialSeed  THEN 

SetSeedValue (1,  InitialSeed) ; 

END; 

NOW  Restart  <-  StartRunNumber; 

FOR  NodelD  :*  1 TO  MaxNodelD  DO 

ReportLevel [NodelD]  SystemReportLevel;  (*  turn  report  control  back  on  if  desired  * 
END; 

| Restart: 

WriteString (ParamOut,  "Run  number  "}; 

Writelnt {ParamOut,  Restart,  0) ; 

WriteLn (ParamOut) ; 

IF  Restart  > StartRunNumber  THEN 
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TermDataElement .SimulationTime  clock; 

TermDataElement .NonCyclicData . Finals® ed  : - GetSeedValue ( 1 ) ; 
WriteDataElamentType (TermDataElement) ; 

FlushDataStructure; 

EndCollectingData ; 

(*  Restore  link  removed  during  previous  run.  *) 

IF  LinkFaults  THEN 

RestoreArc (SourceFaultNode,  DestFaultNode) ; 


END; 


END; 

ReaetTimer; 

StartCollectingData (Experiment Info [ 1] , Experiment Info (2 ] , Experiment  Inf o [3] , 
Restart, Experiment Info ( 4] } ; 

StartDataElement . SimulationTime  clock; 

StartDataElement .NonCyclicData. InitialSeed  :■  GetSeedValue ( 1 ) ; 

{* 

* Tell  everybody  to  go  back  to  initial  state. 

M 

I OS Index  1; 

WHILE  (IOSIndex  <-  6)  AND  { IOS ID ( IOS Index]  <>  0)  DO 

NOW  outport ( IOSPort [IOSIndex] ] A .Reset Command  <-  TRUE; 

INC (IOSIndex) ; 

END; 

FOR  Nodeindex  :»  1 TO  NumberOfNodes  DO 
IF  NetworklNodes [Nodeindex]  <>  0 THEN 

NOW  outport [GetOutPort (NetworklNodes [Nodeindex] )] A .ResetCommand  <-  TRUE; 

END; 

IF  Network2Nodes [Nodeindex]  <>  0 THEN 

NOW  outport [Get OutPort (Network2Nodes [Nodeindex] } ] A . ResetCommand  <-  TRUE; 

END; 


END; 

NOW  outport  [IOServicePort]  A .ResetCommand  <-  TRUE; 

NOW  outport [NetworkManager2Port] A .ResetCommand  <-  TRUE; 

NOW  outport [IOPPort] A .ResetCommand  <-  TRUE; 

NOW  outport [CPPort] A .ResetCommand  <-  TRUE; 

(* 

* Schedule  the  first  application  to  run. 

*) 

AFTER  StartCPFDIRTime  outport [CPPort] A .Submit System  <-  TRUE; 

AFTER  StartlOPFDIRTime  outport [IOPPort] A . Submit System  <-  TRUE; 

FOR  Index  1 TO  3 DO 

AFTER  0.010  outport [ApplicationPort [Index] ] A .ResetCommand  <-  TRUE; 

END; 

(* 

* Start  sampling  at  the  start  of  the  2nd  major  frame.  Note  that 

* the  command  is  only  set  to  the  first  and  fourth  IOS . This 

* is  all  that  is  needed  to  reset  the  network  utilization  probes. 

*) 

AFTER  SecondMa jorFrame  outport [IOPPort] A .ResetProbeCommand  O TRUE; 

AFTER  SecondMa jorFrame  outport [CPPort] A .ResetProbeCommand  <-  TRUE; 

AFTER  SecondMa  jorFrame  outport [ IOServicePort] A .ResetProbeCommand  <-  TRUE; 


AFTER  SacondMa jorFrama  outport (IOSPort [1 ] ] A .ResetProbeCommand  <-  TRUE; 

AFTER  SacondMa jorFrama  outport [IOSPort [4] ] A .ResetProbeCommand  <-  TRUE; 

IF  LinkFaults  THEN 

FaultTima  Random(l,  0.0,  0.040); 

AFTER  (SacondMa jorFrama  + FaultTima)  InsertFault  <-  TRUE; 

StartDataE lament .NonCyclicData .FaultTima  SacondMa jorFrama  + FaultTima; 


ELSE 

AT  Real ToDF lo at ( Simulation Length  - MajorFrameLength)  StopProba  <-  TRUE; 
IF  Restart  - EndRunNumbar  THEN 

AFTER  SimulationLength  StopSimulation  <-  TRUE; 

ELSE 

AFTER  SimulationLength  Restart  <-  Restart  + 1; 

END; 


END; 

WriteDataElementType ( S tar tDataE lament) ; 

| StopSimulation : 

TannDataElament. Simula tionTime  clock; 

TermDataElement .NonCyclicData . FinalSeed  GetSeedValue(l) ; 

WriteDataElementType (TarmDataE lament) ; 

FlushDataStructure; 

EndCollactingData ; 

RasatTimer;  (*  has  affect  of  stopping  the  simulation  *) 

| InsertFault : 

Remo  vaAr  c (Sour  ceFaultNode,  DestFaultNode) ; 

REPORT  "%d, %d"  SourceFaultNode , DestFaultNode  TAGGED  "Removed  link  between  nodes  "; 

WAITUNTIL  (NetworkRaady) 

NatworkRaady : 

TimeToNaxtMa jorFrama  MajorFrameLength  - RealMod(clock  - 0.010,  MajorFrameLength); 

NextMa jorFrama  TimeToNaxtMa jorFrama  + MajorFrameLength; 


AFTER  NextMa jorFrama  StopProbe  <-  TRUE; 

IF  Restart  » EndRunNumbar  THEN 

AFTER  (NextMa jorFrama  ) StopSimulation  <-  TRUE; 

ELSE 

AFTER  (NextMa jo rFrame  ) Restart  <-  Restart  + 1; 

END; 

END; 

| StopProbe : 

IF  StopProbe  THEN 

FOR  Index  1 TO  NumberOfP robes  DO 

SAMPLE  0.0  WITH  SystemProbe ( Index] ; (*  this  forces  the  last  samples  to  be  recorded  *) 

END; 


B-193 


TarmDataElamant.  NonCyclicData.CPTimaUsad  :»  SystamProba [1] A . SumX; 

TarmDataElamant. NonCyclicData. CPTimaAvail  : - SystamProba [1] A .TEnd  - SystamProba [1] * .TStart; 
TarmDataElamant .NonCyclicData . IOPTimaUsed  : - SystamProba [2] A .SumX; 

TarmDataElamant .NonCyclicData. IOPTimaAvail  SystamProba [2] A,TEnd  - SystemProbe[2]A.TStart; 

TarmDataElamant.NonCyclicData.NWTimeUsad  SystamProba [3]  A.  SumX; 

TarmDataElamant . NonCyclicData. NWTimaAvail  SystamProba [3] A .TEnd  - SystamProba [3] A . TS tart; 

TarmDataElamant. NonCyclicData.  IOSysTimaCJsad  SystamProba (4]  A.SumX; 

TarmDataElamant. NonCyclicData. IOSysTimaAvail  : **  SystamProba [ 4 ) A . TEnd  - SystamProba [4] A .TS tart; 
END  ; 

END; 

END; 

END  Controls. 
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PRINCIPAL 


DEVM  principal; 


DEVMS  CentralDB,  I OS,  AIPSNode,  DIU,  IOService,  NetManger,  Applicatn, 

Processor,  Controls; 

DEVC 

RootLinkOutboard  - (OutputTransaction  NodaCommandFrama)  ; 

Rootlink Inboard  - (NodaRasponsaFrama  Input  Transact  ion) ; 

NodaToNoda  - (NodaRasponsaFrama  NodaCommandFrama); 

NodeToDIU  - (NodaRasponsaFrama  DIUCommandFrame)  ; 

DIUToNoda  - (DIURasponsaFrama  NodaCommandFrama); 

SarvicaManagarConn  - ( Manager SarvicaRqst  SarvicaRaquast, 

I0Managar2Rasponsa  IONetworkResponse) ; 

ManagarRaquast  - (IONetworkRequest  IOServiceRequest, 

NewNetworkState  RtnNetworkToService) ; * 

AppRasponsa  - (ApplicationRasponsa  RasponsaApplication) ; 

AppRequast  - (RequastApplication  IOServiceRequest); 

NIOutConnaction  - (ChainToIOS  ChainToProcass, 

Stop I OS  StopChain); 

NIInConnaction  - ( IOChainRasponsa  DataFramlOS, 

ChainFinishad  ChainCompleted)  ; 

Submit  - (ProcessorRaquest  SubaitProcass) ; 

Racaiva  - (Completad  ProcassorRasponsa) ; 

SchAndRasatSystam  - (SubmitSystam  StartSystam, 

RasatCommand  Reset, 

Ras a tProba Command  ProbaRasat); 

SystamReady  - (SarvicaAvailabla  NetworkReady) ; 

ResatSystam  - (RasatCommand  Resat) ; 

RasetProbaAndSys  - (RasatCommand  Reset, 

Res etP robe Command  ProbaRasat) ; 


BEGIN 

ChackQueue  FALSE; 

CheckMamory  : - FALSE; 

Wr i teString (Par amOut, ********  MIRON  IS  DOING  THE  MEMORY  MANAGEMENT  *******"); 
WriteLn (ParamOut) ; 

InitSimulator; 

Simulate (100 . 0) ; 

TerminataSimulator ; 

END  principal. 
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